Date: Wed, 13 Nov 1996 00:52:57 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: asami@FreeBSD.org (Satoshi Asami) Cc: danj@3skel.com, gibbs@freefall.freebsd.org, freebsd-current@FreeBSD.org Subject: Re: ufs is too slow? Message-ID: <199611122354.AAA02103@x14.mi.uni-koeln.de> In-Reply-To: <199611122336.PAA14170@vader.cs.berkeley.edu>; from Satoshi Asami on Nov 12, 1996 15:36:39 -0800 References: <199611122336.PAA14170@vader.cs.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Satoshi Asami writes: > * where did the Linux ext2fs fall? > > It didn't install on our PC with 2940UW. :( (We spent 2 weeks trying > to install that crap, ugh.) Sorry, I already deleted the original message, so I'm replying to this one instead :) I've asked several owners of Linux systems to send Bonnie results, and found that EXT2FS was very much slower than FFS. This lead to the clustering code in Linux being changed, by Gerard Roudier, who had ported the FreeBSD NCR driver to Linux before, and was very disappointed by the lack of file system performance. He acchieved more than a factor of two of improvement on some metrics. The improved clustering plus 4KB allocation blocks (which waste an additional 10% beyond what is reserved to avoid fragmentation) made Linux perform about as good as FreeBSD UFS on all tests except the seek test. The seek values suffered, because of the unconditional read-ahead, if I understand the situation correctly. EXT2FS with 1KB allocation units performs significantly worse than FFS with 4K/512byte. But this is in part due to Bonnie doing 8KB reads, which are very 8K/1K FFS friendly, and still work better given 4KB blocks than 1KB blocks ... (There often was a factor of up to 3 in the rewrite results between Linux and FreeBSD on comparable disk drives, for example. If I remember correctly, the seek rate is now by nearly a factor of 2 lower than before the cluster code changes, and is by about that factor lower than under FreeBSD. But beware of buffer cache effects in that test: Linux tends to use a far higher percentage of memory as a buffer cache!) Linux was unique under Unix operating systems on current hardware in that it was not CPU limited in the "per char" tests (which I use as an estimate of CPU performance on large memory applications :) This was corrected with the new clustering code. I could dig out some numbers from my mail archive, but those are not obtained on recent Linux kernels, and thus are of not too much value anymore (IMHO). Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611122354.AAA02103>