Linux 5.14 SSD Benchmarks With Btrfs vs. EXT4 vs. F2FS vs. XFS

[S.Pam]

Actually, PTS is using old sqlite settings. Most apps these days should use wal mode which is a lot faster on btrfs!

https://wiki.tnonline.net/w/Blog/SQL...mance_on_Btrfs

[Sakuretsu]

After seeing this F2FS is really picking my interest now.

[foobaz]

How come that brtfs is so slow compared to the older filesystems?
Is this how we'd expect out of the box ZFS performance too?

Btrfs is slow because it is a copy-on-write filesystem. This type of filesystem is more reliable but also slower than traditional write-in-place filesystems. I use Btrfs because stability and data integrity are more important to me than raw performance.

ZFS is also a copy-on-write filesystem and so it is relatively slow for the same reasons. ZFS is popular because it is the most reliable filesystem ever created. ZFS is the best choice when you can't afford downtime, data loss, or data corruption. It is NOT a good choice if you're looking for impressive benchmark scores.

[arokh]

Not very interesting benchmarks, in the real world you'd turn off COW (copy on write) for databases, virtual machines etc. F2FS and BTRFS also support Zstd compression, which can actually lead to performance improvements.

[S.Pam]

Not very interesting benchmarks, in the real world you'd turn off COW (copy on write) for databases, virtual machines etc.

No.

Turning off cow also turns off checksums which puts your data in danger. (as much as with ext4). Without checksums, Btrfs can't self heal from disk corruptions, even on raid1 setups.

Of course many applications do use their own checksums internally. On VMs you can sometimes use btrfs as guest filesystem, etc.

We use btrfs in production with both databases and VMs and have not turned off cow. The data integrity is more important than flashy benchmarks. In 99% of cases were not close to any performance bottleneck caused by disk io. Where there is a bottleneck there is usually always ways to resolve it. - if not just get real raw performance hardware https://letsencrypt.org/2021/01/21/n...e-servers.html

[zoner]

I think that this discussion is missing some important variables that directly impact such as the speed of booting and the speed of loading various applications. Some of those variables are:

1. The age of the computer being tested
2. The age and quality of the motherboard
3. The speed of the hdd or ssd and how such drives differ

and here comes a big on:

4. What distro a user is using and all of tweaks and changes inherent to any distro

5. What are all twinks and changes that a user may implement

6. Because each of us has their own thing going on in their brain, we each have a different sense of speed

[intelfx]

if not just get real raw performance hardware https://letsencrypt.org/2021/01/21/n...e-servers.html

Now that's a big ass server all right.

[S.Pam]

No-one in their sane mind would enable COW for databases but of course that's exactly what he will do.

You mean people that value data integrity?

[flower]

No.

Turning off cow also turns off checksums which puts your data in danger. (as much as with ext4). Without checksums, Btrfs can't self heal from disk corruptions, even on raid1 setups.

many hdds and ssds use crc32 internally to verify data. as btrfs uses crc32 too its pretty useless.
and there is still integritysetup - if you use an external drive for integrity it doesnt have ANY performance penality. i am using this in an raid10 setup for quite a while (checksum is sha256)

[coder]

No.

Yes.

Those of you using BTRFS, try this:

sudo lsattr -d /var/lib/*

For me, I get C on mariadb/, mysql/, and pgsql/. Distro: OpenSUSE. If you don't know what that means, read this:

https://btrfs.wiki.kernel.org/index.php/FAQ

I take your point about it disabling checksums, but clearly not everyone shares your priorities.

BTW, there are ways to achieve comparable data integrity on server-grade hardware that don't require filesystem-level checksums, which is why we didn't always have them. See:

• https://www.t10.org/ftp/t10/document.03/03-110r1.pdf
• https://en.wikipedia.org/wiki/ECC_memory