Drastic performance issue in ext2 v ffs

Tom Christiansen (tchrist@jhereg.perl.com)
Tue, 05 Jan 1999 12:41:59 -0700


I believe there is something dramatically wrong here, probably in either
the ext2 filesystems or the SCSI driver, or both. Here's the story.

I have two boxes. One is a Pentium-Pro (200 Mhz) running a Linux 2.0.36
kernel under Redhat 5.2. The other is a Pentium-II (300 Mhz) running
OpenBSD 2.4. Both have 128M memory and large SCSI disks. Linux is
using ext2 filesystems, and BSD ffs filesystems.

The deal is that I ran recursive directory operations on duplicate
directories (about 55meg) on each machine, and no matter what I did,
the Linux times were more than an order of magnitude worse. I can't
account for that, and I'd like to.

My first test was du on that directory tree. Here are the timing results
of "du -s >/dev/null".

linux 0.080u 11.400s 0:11.51
bsd 0.030u 0.462s 0:00.49

That I found remarkable. So I tried find.
Here are timings on "find . -ls >/dev/null":

linux 1.050u 12.130s 0:13.35
bsd 0.739u 0.445s 0:01.18

Of course, these are not identical version of du and find. For example,
the GNU du is 854 lines compared with BSD's 255 lines, largely due to
leveraging ffs(3) to do the real work.

So I decided to try duplicate programs. I used "find2perl . -ls |
perl5.005_54" and timed that output. This time I know that the code is
the same. Here are the results:

linux: 5.000u 13.250s 0:18.34
bsd: 2.3u 0.7s 0:02.94

So, what might account for this embarrassingly dramatic disparity?
Does BSD have an incedibly better inode cache? Is this a known
bug? Is it fixed in the next release? :-)

--tom

-- 
    "Premature optimisation is the root of all evil."
					--Knuth

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/