Another dusty benchmark: Filesystem Torque Curves, gentoo 2.4.18

Filesystem Torque Curves, gentoo linux 2.4.18 5400rpm maxtor 80gig on athlon xp1700

Doing more cleaning, and dusted off an old filesytem benchmark deserving of notice.

This benchmark was built from a bash script that formatted the same partition each time with different filesystems and the -o options shown on the legend.

dbench was run with x processes and then the filesystem was wiped and formatted as above and the buffers purged. I ran this many times and got comfortable with the relative numbers being consistent, so this may represent only 1 test run but it was pretty stable at the time.

dbench runs a recorded session of deliberate samba abuse * n processes; A collection of large file operation and inode abuse.

Presently this machine is an anonymous motherboard sitting on a shelf in a stack next to a collection of anonymous old hard drives these days.

I wrote this benchmark to see if I was actually missing out on something that XFS brought to the table. I tend to go with reiser3 (tails rock for all things portage) for general purpose filesystems and ext2 or huge swapfs for performance workloads such as processing multimedia or mythtv sandbox.

XFS was touted as the coolest filesystem and supposedly excelled at all things for all needs according to several zealots I've run across. I always thought that it looked a bit contrived compared to ext2 and had less thought to detail than reiserfs. i had no idea those 2 filesystems would leave it in the dust until I ran the benchmark.

I'm fascinated these days with LinLogFS -- A Log-Structured Filesystem For Linux or Linux Log-structured Filesystem Project but the applications haven't presented themselves frequently.

Other items of note from this benchmark

• dbench probably offers some opportune areas for inflated numbers corresponding to the force of numbers of developer man-years exposed to the linux driver module in question... where..
  
• ext2's implementation is brutally terse with good results and lots of eyes and hands contributing vfs enhancements based on ext2 being the gold standard to cater around. (vfs doesn't seem so simple since this benchmark's kernel version)
  
• Reiser shows the oddest process load harmonic. there's some nitrous in concurrent power of 2 access there...
  
• JFS was having a really awful hair day at the time.
  
• Minix crapped out on more than 2 processes effectively breaking the script and 0's were padded in.
  
• pagesize as blocksize makes all the difference on fsbench.
• journaling overhead seems to be an option that's somewhat costly for general diversified workloads. if you dont care about the data persistence, then you probably want the fast edition of the data, and won't need a fsck when a mkfs is plenty sufficient and takes a fraction of the time (such as with high performance computing processing nodes and various web state).

PDF: filesystem benchresults
Google Doc: spreadsheet include interval timings