Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.uoknor.edu!news.nodak.edu!netnews1.nwnet.net!news.u.washington.edu!uw-beaver!uhog.mit.edu!news.mathworks.com!gatech!newsxfer2.itd.umich.edu!agate!nickkral
From: nickkral@america.CS.Berkeley.EDU (Nick Kralevich)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 16 Feb 1996 03:05:58 GMT
Organization: Electrical Engineering Computer Science Department, University of California at Berkeley
Lines: 131
Message-ID: <4g0sam$r6p@agate.berkeley.edu>
References: <4er9hp$5ng@orb.direct.ca> <4fjodg$o8k@venger.snds.com> <311DA774.167EB0E7@FreeBSD.org> <31220995.C4C54C1@acm.org>
NNTP-Posting-Host: america.cs.berkeley.edu
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14353 comp.os.linux.development.system:18005
In article <31220995.C4C54C1@acm.org>, Dana Jacobsen <dana@acm.org> wrote:
>Did I notice a performance difference? Yes and
>no. Doing recursive rm's on large directories was noticibly slower. Big
>deal -- how often do I do that, and besides, it was maybe 2 times slower at
>maximum. The disk was active more often (which is to be expected). But
>overall I hardly noticed at all.
The USENIX 1996 Annual Technical Conference had a submission titled
"A performance comparison of UNIX operating systems on the Pentium".
In the extended abstract, they claim "On small file workloads, LInux is
order of magnitude faster [10 times] than the other systems [FreeBSD
and Solaris]". (items in brackets were added by me).
As for some numerical data regarding the speed of Linux vs FreeBSD
filesystems, I saved the following article which was posted a couple
of months ago. The numbers are sorta old, but I don't think that much
has changed with regards to the filesystems of Linux or FreeBSD,
especially in light of the report from the USENIX technical conference.
Disclaimer: I didn't write the article below. Please be sure that
followup attributes are correct.
From: tytso@dcl.mit.edu (Theodore Y. Ts'o)
Newsgroups: comp.os.linux.development.system,comp.sys.powerpc
Subject: Re: ANNOUNCE: Linux/PowerPC Kernel
Date: 09 Aug 1995 20:30:19 GMT
From: ghudson@mit.edu (Greg Hudson)
Date: 3 Aug 1995 13:38:43 GMT
All that said, you may be quite right about synchronous meta-data writes
being unnecessary for stability. I'm not really qualified to debate the
necessity of such a design decision. It remains the case that, in my
experience, FFS achieves performance equal to or better than that of
ext2fs and significantly better reliability.
Wow.... I'm entering this flame war at the end, and I don't want to fan
the flames some more..... however, at the risk of injecting some actual
facts into the discussion, let me post the following benchmark results
which were presented by Remy Card at the Amsterdam Linux Symposium.
They're a bit dated at this point (from December 94), so they don't
reflect the latest performance improvements that have gone into both
kernels (although I don't know how much additional work has gone into
optimizing the BSD FFS; I do know that the work to optimize ext2fs is
still on-going).
The following benchmarks were done using a stabdalone i486DX33 with 16
MB of RAM, and Western Digital Caviar IDE drives. The Linux kernel
which was used was Linux 1.1.62. The BSD kernel that was used was
FreeBSD 2.0 Alpha, based on the 4.4 BSD Lite distribution. The block
size used by the BSD FFS was 4k with 1k fragments; the block size used
by the Linux ext2fs was 1k blocks (the ext2fs cluster code provides most
of the performance gains of going to 4k blocks with 1k fragments, so
it's unlikely that ext2fs will actually implement support for
fragments).
The first benchmark that was done is the Bonnie Benchmark. It has the
following stages:
* Writes data to a file (using character I/O)
* Rewrites the file
* Writes data to the file (using block I/O)
* Reads the file (using character I/O)
* Reads the file (using block I/O)
* Seeks into the file
The benchmark was done using a 60MB file (which is the limit of XiaFS, a
much older and by now somewhat obsolete Linux filesystems):
Char Block Rewrite Char Block Seeks
Write Write Read Read
KB/Sec KB/Sec KB/Sec KB/Sec KB/Sec /Sec
FFS Async 710 684 401 721 888 27.6
FFS Sync 699 677 400 710 878 27.4
Ext2 FS 452 1237 536 397 1033 46.6
Xia FS 440 704 380 366 895 36.0
Note that character-oriented read()'s and write()'s are slower under
ext2fs, but as soon as you start doing block oriented writes, ext2fs
blows away the FFS --- and it doesn't much matter whether the FFS
filesystem was mounted with or without the async flag.
The second benchmark that was done was the Andrew Benchmark, which was
developed at CMU and used at Berkeley to benchmark the FFS and LFS. It
has five phases:
* Create a directory hierarchy
* Make a copy of the data
* Recursively examine the status of every file
* Examine every byte of every file
* Compile several of the files
Each of these tests were run 10 times for each filesystem and the
results were then averaged. Unlike the previous benchmark, the results
are in milliseconds, so lower numbers are better:
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Create Copy Stat Grep Compile
(ms) (ms) (ms) (ms) (ms)
FFS Async 2203 7391 6319 17466 75314
FFS Sync 2330 7732 6317 17499 75681
Ext2 FS 790 4791 7235 11685 63210
Xia FS 934 5402 8400 12912 66997
In this benchmark, Linux beats out the FFS (either Async or Sync) in all
categories except phase 3. Stephen and I have started looking into this
problem with a view towards correcting it, and it seems to be directly
related to the speed of stat(), which is currently embarassingly slow
(at least compared to ext2fs's performance in other areas).
Unfortuantely, I haven't had much more time to look into this since the
Berlin Linux conference, but I'm sure we'll be able to fix this
performance problem during the 1.3 development cycle.
- Ted