9-Way File-System Comparison With A SSD On The Linux 3.17 Kernel

[phoronix]

Phoronix: 9-Way File-System Comparison With A SSD On The Linux 3.17 Kernel

Sunday benchmarks this week on Phoronix are comparing nine popular, mainline file-systems present within the Linux 3.17 kernel. All the usual contenders are present and the benchmarks happened with a solid-state disk.

http://www.phoronix.com/vr.php?view=20877

[Apopas]

Are these results normal for JFS or the delayed writes play some kind of trick and the test suite thinks that it is that fast?

Thanks a lot for the benchmark, Michael. It was very helpful since I'm building a new media centre with one SSD and two SATAs.

[sdack]

Btrfs is somewhat disappointing, but F2FS is looking good.

All in all nothing to write home about except perhaps to warn people on JFS.

[wmax]

Results of this test may seem misleading

The results of this test I trust are accurate, but the settings on the file systems are Linux defaults and thus misleading. This means that F2FS may seem better because by its nature it is optimized for SSD (like the ones used in this test). The other file systems are not targeted at SSDs, and therefore have more neutral settings, not settings tuned for an SSD.

The default settings used on Btrfs (for example) are relatime, rw, space_cache, sdd

Settings better optimized for an SSD would probably be noatime, discard, ssd, autodefrag, compress=lzo, space_cache

[gens]

Settings better optimized for an SSD would probably be noatime, discard, ssd, autodefrag, compress=lzo, space_cache

noatime is not for everybody, and it would speed up all them filesystems
most any kind of defrag has no effect on ssd's
compress also speeds up all dem who support it (ext4 i know can do it) and it wouldn't do anything with movies, pictures and other already compressed files
idk about others

[dragonn]

noatime is not for everybody, and it would speed up all them filesystems
most any kind of defrag has no effect on ssd's
compress also speeds up all dem who support it (ext4 i know can do it) and it wouldn't do anything with movies, pictures and other already compressed files
idk about others

I use for ext4 noatime,nodiratime,discard,journal_checksum,journa l_async_commit,data=ordered for my it gives best result without disabling journal (with causes often data corruption after hard reboots).

[liam]

Btrfs is somewhat disappointing, but F2FS is looking good.

All in all nothing to write home about except perhaps to warn people on JFS.

It shouldn't be disappointing. BTRFS has mnay mount options that can radically change behavior (iirc, it should detect ssds and put itself into the appropriate mode, but that isn't necessarily it's fastest mode).
f2fs should be, when it's ready, the fastest, RELATIVELY safe option...but it's not there yet, iirc (i don't believe they've completed work on an fsck-fixer for when the system loses power during writes---this wasn't a priority since it was intended for battery powered devices, but even those can experience kernel panics/sudden power failures).
Does anyone know if ibm is still doing any serious work on jfs, or is in maintanence-mode?

[liam]

most any kind of defrag has no effect on ssd's

If that were true then random read=sequential read.
Until access times are in the ns range, it will matter.

[sdack]

It shouldn't be disappointing. BTRFS has mnay mount options that can radically change behavior (iirc, it should detect ssds and put itself into the appropriate mode, but that isn't necessarily it's fastest mode).
f2fs should be, when it's ready, the fastest, RELATIVELY safe option...but it's not there yet, iirc (i don't believe they've completed work on an fsck-fixer for when the system loses power during writes---this wasn't a priority since it was intended for battery powered devices, but even those can experience kernel panics/sudden power failures).
Does anyone know if ibm is still doing any serious work on jfs, or is in maintanence-mode?

No, I agree it should not, which is why it disappoints me. My thinking is to stick with Ext4 for myself now, because I have been with Ext2/3/4 for a long time, and I do not see Btrfs out classing it. And when I want to go with an SSD-only system, which I think is where it is taking me eventually, then I rather want a file system specifically designed for SSDs, and only SSDs, and not one which does both, old and new.

[liam]

No, I agree it should not, which is why it disappoints me. My thinking is to stick with Ext4 for myself now, because I have been with Ext2/3/4 for a long time, and I do not see Btrfs out classing it. And when I want to go with an SSD-only system, which I think is where it is taking me eventually, then I rather want a file system specifically designed for SSDs, and only SSDs, and not one which does both, old and new.

IMHO, btrfs offers enough features that it is with moving towards with the understanding that some features are better supported than others. It now seems solid enough that I'd recommend its usage for an average user as long as they are using conservative mount options.
Even with those you get fantastic benefits you have an intruding enough fs that it is able to act as the foundation to lennart's new proposal regarding system rollouts/updates/versioning.
Eventually, it should contain features that no other non-clustering fs offers.