Linux 4.4 To 4.7 - EXT4 vs. F2FS vs. Btrfs Benchmarks

[phoronix]

Phoronix: Linux 4.4 To 4.7 - EXT4 vs. F2FS vs. Btrfs Benchmarks

I've been a bit behind on my file-system benchmarking the past few months but for your viewing pleasure today are some EXT4 vs. Btrfs vs. F2FS file-system tests on an NVMe SSD when testing the Linux 4.4, 4.5, 4.6, and 4.7 kernels.

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

[balouba]

F2FS looks promising!

[SaucyJack]

F2FS looks promising!

Too bad it's a pain to get working for your boot device. They really need to fix that shit.

[RedBlitz]

Would there ever be any benchmarks regarding filesystem performance on SAN attached disks? We are getting an all SSD array up and running and would be interested in comparing xfs, ext4 and zfs. I love what you're doing, keep it up.

[ObiWan]

On UEFI with systemd-boot or refind it's as easy as any FS (as /boot is the FAT32 EFI partition)

Only with GRUB there are problems with a F2FS /boot as long as it doesn't support it out of the box

[Michael]

Would there ever be any benchmarks regarding filesystem performance on SAN attached disks? We are getting an all SSD array up and running and would be interested in comparing xfs, ext4 and zfs. I love what you're doing, keep it up.

Unfortunately lack all the needed hardware to do such tests well...

[oleid]

When doing the RAID test, please include btrfs in single disk mode on mdraid. I found this combination more reliable than using btrfs' internal mirroring.

[leonmaxx]

Btrfs's random write speed better than sequential write speed.
Something is wrong in this life.

[kobblestown]

When doing the RAID test, please include btrfs in single disk mode on mdraid. I found this combination more reliable than using btrfs' internal mirroring.

In what sense is it more reliable? You are aware, that in your suggested setup you'd loose the Btrfs recovery capabilities, right? I've used Btrfs with its own RAID1 support (more than 5 years already with 2, then 3 and now 4 disks) and never had any problems. Actually, it saved my ass once because it was able to identify the wrong blocks and recover them from the mirror image. When the mirroring happens at the lower level it can only detect an error but not correct it. Also, the scrub is unreliable because there's no guarantee that erroneous blocks will be read by mdraid - maybe it only ever comes from the correct mirror image. And you may only discover it when it's too late - when the healthy image kicks the bucket and you are forced to read from the other one - which is wrong but you never knew it. If you don't trust the Btrfs RAID capabilities I'd suggest you don't use it at all. I wouldn't.

[kobblestown]

Also, I wonder (in the sense that I spent several minutes in Google without finding definitive answer) how do mdraid/lvm implement RAID1 with 3 disks. Is it a 3-way mirror or invalid configuration? In btrfs it's totaly fine and you get 1.5x the size of the disks (assuming same size) and it can tolerate the loss of any single disk. Something like RAID5 with lower capacity but better performance.