Date: Sun, 1 Apr 2001 21:14:17 -0700 (PDT) From: Dan Phoenix <dphoenix@bravenet.com> To: Charles Burns <burnscharlesn@hotmail.com> Cc: questions@freebsd.org Subject: Re: how can you say ufs is faster? Message-ID: <Pine.BSO.4.21.0104012107450.31373-100000@gandalf.bravenet.com> In-Reply-To: <F118eFUtLch9wPiyAph00014f65@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I am not disagreeing with you for your case study or OS for that matter as I do prefer freebsd much over linux anyday. IN a test I did where qmail was overloaded with mail on both a linux fs then a freebsd fs, linux fs outperformed freebsd no problems. Ufs , maybe i am wrong but is way slower when writing to files. Maybe reading sure.....but i am convinced writing there is no way. What i ended up doing was just striping 3 scsi drives together with vinum on freebsd because i try not to use linux unless SMP is a major factor. IF you look over current SMP code in kernel i can say linux and solaris do it way better......and there is no way fbsd can do it without a complete re-write of kernel which they are promising in 5.0....but we will see. I really question your benchmark program.... what do you use and your stats were based on more than 1 benchmark test right? On Sun, 1 Apr 2001, Charles Burns wrote: > Date: Sun, 01 Apr 2001 21:03:49 -0700 > From: Charles Burns <burnscharlesn@hotmail.com> > To: questions@freebsd.org, dphoenix@bravenet.com > Subject: Re: how can you say ufs is faster? > > I am just citing my own tests. Transfering large streaming files was about > 2% faster and transfering small files (4k) was about 6-8% faster. > There are other factors in filesystem performance besides whether files are > mounted synchronously or asynchronously, such as cluster size, metadata > overhead, fragmentation, whether the FS is tuned for large or small files, > whether the FS is designed to defragment itself in real time (like UFS) and > how much effort it puts towards doing this (configurable with tunefs), the > controller chip, the IDE driver, and even the physical location of the files > on the hard drive. > > My tests could be wrong, as I never intended them to be true scientific > comparisons. Note, however, that I tuned the filesystem on the Linux system > using "hdparm" and did no tuning whatsoever with the FreeBSD system. > > The hard drive tested was a Maxtor DiamondMax Plus 40GB drive with 2 megs of > 100MHz SDRAM cache. The drive is ATA100 capable, but is on an AMD751 > controller so is at ATA66. The CPU is an Athlon classic at 750MHz, 1/3 speed > cache memory (not the default of 1/2 speed). The files were not cached in > RAM and both tests were on freshly installed systems. The Linux distribution > was Slackware 7.1 and the FreeBSD installation was 4.2-RELEASE. > > Besides, you can mount UFS partitions asynch if you really want to. > > If your benchmarks show that Linux's EXT2 is faster, more power to you. I > have other reasons for using FreeBSD even if that is indeed the case. > > "Use the right tool for the right job" :) > > Charles Burns > > >From: Dan Phoenix <dphoenix@bravenet.com> > >To: burnscharlesn@hotmail.com > >Subject: how can you say ufs is faster? > >Date: Sun, 1 Apr 2001 16:30:01 -0700 (PDT) > > > > > >ext2fs uses asyncrounous mounts. > >more potential for data loss but a linux filesystem is quite faster > >on say a single ide drive. > > > > > > > > > > > >-- > >Dan > > > >+------------------------------------------------------+ > >| BRAVENET WEB SERVICES | > >| dan@bravenet.com | > >| make installworld | > >| ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | > >| ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | > >+______________________________________________________+ > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.21.0104012107450.31373-100000>