Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS

[phoronix]

Phoronix: Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS

With all of the major file-systems seeing clean-up work during the Linux 4.21 merge window (now known as Linux 5.0 and particularly with F2FS seeing fixes as a result of it being picked up by Google for support on Pixel devices, I was curious to see how the current popular mainline file-system choices compare for performance. Btrfs, EXT4, F2FS, and XFS were tested on a SATA 3.0 solid-state drive, USB SSD, and an NVMe SSD.

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

[linner]

Please re-run tests on top of dm-crypt. I don't know ANYONE that runs plain unencrypted disks any more. Every disk is full encryption with no exceptions because as we have all seen, leaking data can end your company. Of course encryption doesn't magically fix all possible cases. However, the main risk is quick theft were they steal the drives/systems without trying to get in to them beforehand and those will be protected.

[patrakov]

Please re-run tests on top of dm-crypt. I don't know ANYONE that runs plain unencrypted disks any more.

Well, I do, on my desktop, but I do plan to change that (currently pending on the research regarding the existing remote unlock mechanisms), and all my laptops were encrypted since 2008.

What would be also interesting is to quantify snapshotting/COW mechanisms other than BTRFS, in the situation where snapshots are not actually used:

1. XFS with "-m reflink=1" passed to mkfs. Yes I know, not a supported configuration in distribution installers, but still applicable to manually-added mounts. Compare to out-of-the-box XFS and to BTRFS.

2. Test ext4, F2FS and default XFS on top of an LVM volume (let's say 50% of the device size, if it matters) instead of the plain partition. Compare to the same filesystems on a plain partition, plus BTRFS on a similar partition.

3. Test ext4, F2FS and default XFS on top of a thinly provisioned LVM volume. Compare to the same filesystems on a plain partition, plus BTRFS.

[schmidtbag]

Please re-run tests on top of dm-crypt. I don't know ANYONE that runs plain unencrypted disks any more. Every disk is full encryption with no exceptions because as we have all seen, leaking data can end your company. Of course encryption doesn't magically fix all possible cases. However, the main risk is quick theft were they steal the drives/systems without trying to get in to them beforehand and those will be protected.

I run plain unencrypted disks for all of my home PCs.

[AndyChow]

Please re-run tests on top of dm-crypt.

IMO, these tests are meant to track the FS performance. With dm-crypt/LUKS, you introduce too many variables, such as cypher, AES-NI accel, etc. So I like the test as is.

That said, I am curious about if any results would be different with LUKS. I'm guessing the penalty would be about linear straigth-up, and no change in ranking. But I am just guessing.

[birdie]

I wouldn't care even if XFS/BtrFS/whatever were five times faster than ext4 cause it's the only filesystem which offers an extensive set of tools to restore data (including R-Studio Undelete). Yeah, I know about backups but sometimes people don't have them or they fail.

[treba]

It's weird how BTRFS performs so well on the NVMe and so bad when connected vie SATA. What's so different there?

[linner]

I run plain unencrypted disks for all of my home PCs.

Crazy! This is one of those things you don't think can happen to you, until it does. What if someone steals your computer? You want them to have access to everything?! With modern CPU's encryption costs practically nothing, there is no reason not to do it.

[Danielsan]

Recovering data from an encrypted drive damaged or messed-up is almost impossible, I have much more personal experience of hard-drives broken than computers stolen, and between the two risks I prefer keep my hard-drivers unencrypted.

[mv.gavrilov]

Please add HDD in the test and bcachefs.