XFS / EXT4 / Btrfs / F2FS / NILFS2 Performance On Linux 5.8

[antonyshen]

Regarding to the slow EXT4 results, I don't think it's related to Ubuntu 20.04. The tests were carried on Kernel 5.8 which is not the one released with 20.04, and all filesystem drivers are provided by the kernel not the distro.

[Jigglywiggly]

Could this test be done on the default kernel with Ubuntu 20.04? I really am surprised to see ext4 performing so badly, and am wondering if I should swap to xfs.

[Michael]

Could this test be done on the default kernel with Ubuntu 20.04? I really am surprised to see ext4 performing so badly, and am wondering if I should swap to xfs.

This test was done on Linux 5.8 to be more forward looking towards future distro releases. At least off the top of my head, the outcome largely jives with what I've seen from recent 5.x releases.

[esbeeb]

Great comparisons! I had no idea the performance could vary so much.

I'm tempted to use xfs for root partitions in the future, for the speed (plus the maturity/stability of xfs seems to have a non-controversial reputation), however I'll still be turning to btrfs when I need snapshotting (like in a NAS build), and ext4, when I want transparent encryption (say, on external media, which I know I'll never share with Windows users).

Note: I'm not a fan of zfs.

[Jigglywiggly]

Is f2fs stable enough for daily usage, and does the ubuntu installer have an option for f2fs?

[gregzeng]

Where's FAT32, UDF, exFAT, NTFS etc. This is only half the widely used file systems. Linux supports them all.

Microsoft's exFAT & NTFS is now "open source" it seems, via Microsoft's membership of the OIN - Open Invention Network.
The Open Source version of NTFS should be scrapped.

[gregzeng]

Regarding to the slow EXT4 results, I don't think it's related to Ubuntu 20.04. The tests were carried on Kernel 5.8 which is not the one released with 20.04, and all filesystem drivers are provided by the kernel not the distro.

Examine the graphic in the first page, very closely. The test was done with the latest available DAILY ALPHA release. By deliberate design, these are very, very unstable. They add experimental features that may be too immature to ever be released into any version of Linux.
When bench testing, perhaps the benchtest version might best be chosen. This version is optimized for AMD64, with low latency. Users who value benchtest results might prefer Linux kernels designed for good bench test results.

It matters not whether it tells us about Ubuntu 20.04, because we just need one constant operating system for different types of partitions. Each partition type may also be better fine-tweaked, to determine a better performance criteria. The administrator will need to determine where the compromise point might be: safety, speed on read, speed on write, speed on random access, self-repair, emergency repair, self-maintenance, etc.

Each partition type handles these various optimizations badly or well. Each is assisted or handicapped by several other factors. Each has varying rates of upgrades, bug fixes & reliability. There are probably never the one true decision for all the many future uses & situations. This Phoronix result is just one of the many findings that help us to make a better decision.

[kylew77]

The one good thing about LInux versus the various *BSD operating systems is file system choice: ext4, ext3, ext2, F2FS, BTRFS, XFS, JFS, and others. In BSD world you get UFS/FFS and then ZFS if you are on FreeBSD or NetBSD and Hammer2 if on Dragonfly.

[Old Grouch]

My last test with NILFS2, not merely "benchmarks", but actually trying to use its features showed a lot of kernel module crashing. What kernel are you using? Just curious. What I like about NILFS2 (if it is stable, which I doubt) is that you can come the closest to having a true versioning filesystem vs typical snapshotting.

I got frustrated by it recently. So, while I like some of its features, my fear is that is has gone into decay with regards to maintenance and testing.

I'm currently using a kernel from the Ubuntu mainline ppa
5.3.10-050310-generic

I can't upgrade because of...drumroll...a kernel crash in NILFS2 in later kernels, which should now be resolved, but because the Ubuntu mainline build process currently fails self-tests on AMD64, I don't have access to a fixed kernel unless I start compiling them myself. It is one of several things pushing me to drop using Ubuntu.

The patch to resolve the issue* is pretty recent, and was needed (I believe) because of a change in the underlying kernel functionality. I share your disquiet about NILFS2 going into desuetude. Like you I believe that NILFS2 comes closest to having a true versioning filesystem. I got used to DEC FILES-11 ODS-2 and its versioning, and continue to be surprised that it's not a standard feature of any mainstream Linux filesystem. It has 'saved my bacon' more than once, which is why I like NILFS2 and earnestly hope it has a viable future, or that F2FS gets more NILFS2-like capabilities.

My setup is unusual because I have / on NILFS2, partly as an exercise to show that it is possible. So far, the problems I have had have been caused by kernel issues and not by NILFS2 code, so in my use the NILFS2 code has been reliable.

*You can work out which kernels it applies from by looking at the linux kernel mailing list here: https://marc.info/?l=linux-kernel&w=2&r=1&s=konishi&q=b

[intelfx]

On a single drive laptop SSD btrfs found all kinds of metadata sequence and checksum errors after a battery-empty power-off. The drive had obviously not written all the data it claimed it had written. Had to recover from backups, although btrfs restore did work to copy off the data from the drive. There were no significant differences from the last backup though.

That’s the worst possible scenario for btrfs. Unfortunately it is extremely sensitive to unwritten data problems (broken write cache behavior in certain drives). Even one lost write (when the drive says that the data was succesfully written to stable media but in fact it wasn’t) in metadata path is enough to irreversibly corrupt the whole filesystem.