[plug] Filesystem benchmarks

[Adrian Chadd]

On Wed, Oct 04, 2006, Shannon Carver wrote:
> That was the one I read! Thanks..
> 
> Quite frankly, its s#$ts all over ReiserFS.  I'm considering rebuilding my
> main machine from ground up, with XFS for everything... We'll see.  Is it
> worth a week long Gentoo compile :P
> 

Ah, filesystem benchmarks. How I stab at thee.

* This benchmark made no attempt to simulate a year-old filesystem.
  Degredation over time is more important than speed at initial creation!

* He made no attempt to simulate real-world filesystem management.
  Stuff like "run live fsck or defrag", "resize filesystem", etc.
  You know, the stuff that matters when you're slowly adding gigabytes to
  your fileserver (LVM is awesome for stuff like that..)

* No attempt to simulate catastrophic failure. I remember the ext3 guy rant
  about why he chose full metadata journalling rather than 'change' journalling:
  XFS as an example only journalled changes to inodes which is great when you
  need to replay a crash but horrible when your crash was during a period of
  heavy IO and random crap was scribbled over your inode table. The journal
  just doesn't have enough information to recreate the inode table or directory
  table. Ext3's JBD pays a performance penalty but makes up for it by being
  reliable on craptastic PC hardware. (SGI solved the problem by putting honking
  enormous caps on their powersupply lines and adding in a "power out" NMI which
  the OS then took to mean "CANCEL ALL PENDING IO IMMEDIATELY, WE'RE SINKING."

* CPU performance is misleading. Whats the breakdown of CPU usage? How much
  time is userspace? How much time in kernel space? How much time in IOWAIT?
  An interesting question is the latter: how efficient is the filesystem with
  lots of SCSI disks in a RAID array? How efficient is the filesystem with
  one enormous non-NQ terabyte SATA raid stripe? How much time is wasted?
  Was it pegged at 99% because the CPU was doing 1% of filesystem work and
  99% of tar work? Or was only 20% being used because the other 80% was being
  spent in IOWAIT? etc.

Lots more problems with this article. He didn't, for example, cover the
Reiserfs tendency of old to treat dd'ed images of reiserfs filesystems as
parts of the main filesystem; reiserfs's utilites then did a great job of
making it all one enormous and confusing FS. Lucky for me I know better and
don't run ReiserFS, no matter how sexy its appeal is :)




Adrian