Finding the Fastest Filesystem, 2011 Edition

It looks like XFS is still the fastest for the majority of test but brtfs is a very close second. I'm not at all surprised. I've been a fan of XFS since I supported SGI servers and workstations way back when. XFS is one piece of SGI's legacy that survives, and deservedly so. I just wish it had all the Linux tools that exist for ext3/4.

I thought it odd that he mounted ext3 with the performance boosting "noatime" option but did not also mount reiserfs with that same option - which, along with the "notail" reiserfs mount option, is clearly explained in the linux mount manpage and would have greatly increased performance. Although I'm using ext4 these days, back when i was using reiser, all of the benchmarks I could find and run showed reiser to be significantly faster than ext3.

BTW I found the most recent phoronix filesystem benchmarks of interest - they also showed xfs as being the fastest in most tests.

All filesystems got "noatime,nodiratime". The options specified with each test, were in addition to those.

As for the tools for XFS, they're there, just under different names (and therefore not available under their generic names during boot-up *sigh*).

@gus - I must have missed the fine print. When I was reading what he said about reiser, I thought he said something like "I couldn't find any documentation on reiserfs mount options so I didn't use any" - my bad if I misunderstood.

Thanks for the clarification about the xfs tools.

"He"? Check the byline...

BTW, caitlyn, btrfs didn't approach the best performers during the normal testing, but it did scale supremely well. The chart at the end shows what it did up to 50 threads.

@gus - no disrespect intended. byline duly noted.

I was very interested to read about "noatime", I've put that in my fstab, let's see if there is any perceptable speed-up.

Woops. It looks like I was confusing RAID1 (mirroring) and RAID0 (striping) on the btrfs tests. I'll re-run them and update the results.

The article and its figures are updated, with the RAID0 correction on btrfs.

The overall conclusions haven't changed.

I have to admit XFS is pretty impressive - especially if you compare it to other file systems from corporate origins. At one time I thought IBM's JFS looked pretty promising, but now that the dust has settled it's clearly no world beater. IIUC IBM started the linux port of JFS not with the AIX filesystem code, but with the OS/2 code (the less advanced code as I understand it), ported it to linux, debugged it, and it's basically been coasting since then. On the other hand, SGI's generous gift to linux, XFS, has received not only maintenance but steady enhancements over time. It's good to see a corporate contribution that actually shines.

BTW, in mount(8) the explanation of the reiserfs "notail" option indicates that it's for compatibility with LILO. It says nothing about affecting performance, at least on my system.

http://www.funtoo.org/en/articles/linux/ffg/2/

See paragraph: "Tail packing pro's and cons"

I tested "notail", adding it to "noatime,nodiratime" and also a round with "sync" added.

With 5 threads, "notail" (but no "sync") had about a 3% performance impact on two individual runs, one dropping, one improving (average: no appreciable difference). With 20 threads, all numbers dropped at least 5%.

Adding "sync" to the mix made it even worse.

Interesting results...

My testing during the 2003-2006 era showed reiserfs soundly trouncing ext3, jfs and xfs in every benchmark I could come up with. I suppose it goes without saying that things change over time, especially in the IT world.

I purposely omitted ReiserFS in my earlier stuff, because of the tendency to route around the Linux VFS infrastructure. But if I'm going to include the experimental btrfs, I should also include ReiserFS, to be fair.

Incidentally, going with sync mounts made Ext4 a much stronger contender than XFS.

gus3: But did you try with tiny files or not? I'll try to do a benchmark soon.

ed: Did, also tried two times; Linux kernel no difference, bzipped-portage tree is ~5% faster without tails. Which actually makes sense. No big difference though.

AFAICT, dbench tests operations on many small files. Tail operations have lots of opportunities on that kind of test.

Sorry about the delay in answering; I haven't had 'net access for a couple days.

No problem, glad you're back!

Some stats: 119k files in portage, of which 71k smaller than 1024 bytes. I'm not sure what the limit is for tail packaging. Probably not very interesting anyway, unless you're copying these kind of files whole day, and I think your research shows ReiserFS doesn't offer good performance anyway.