An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11

[leledumbo]

BTRFS continues to show disappointing performance. My decision to go back to EXT4 was right.

[gregzeng]

It would be interesting to see a file system benchmark include NTFS on Windows 11, APFS on macOS, HAMMER2 on DragonFly BSD, and UFS on FreeBSD.

NTFS has the official Microsoft version, and the open source Linux version. Error detection and error correction is included most times, with the Microsoft version. Unsure whether the Linux version has this feature.

For users of personal computers, with limited budgets and computer sizes, there are two file systems with real time compression included. Commercial NTFS and btrfs. Linux only specialists seem both constrained by budgets or sizes. This explains why most personal computer users stay away from Linux.

Most Linux people seem happy with ignoring the personal computer users. Is Pheronix also very happy with ignoring most users of personal computers?

[jstoik]

That was an awful showing by btrfs. IT was slowest or performed the worst (practically) on every test. Yet, it's the default for a number of distros.

Unless your day-to-day workflow resembles a stress test, you'll be unlikely to notice any meaningful performance differences between Ext4 and Btrfs. If it takes about a second to open Firefox from an Ext4 partition on your system, it'll take about a second to open it from a Btrfs one too.

There are performance differences, to be sure, but at normal scales, they're just not that relevant.

What can be relevant, though, are all the extra features "modern" file systems like Btrfs and Zfs and Apple-whatever-the-fuck bring to the table, like copy-on-write, compression, snapshotting, mirroring, etc.

On my laptop, for example, I keep a week's worth of daily full-system snapshots and, for good measure, sync the Friday copies each week to two different external USB hard drives. Thanks to CoW, the local versions take no time at all to generate and never weigh much more than a few gigs (despite representing more than a terabyte of actual data). The remote copies are necessarily the same size as my local file system, but because Btrfs supports incremental syncs, it doesn't take much to bring them up-to-date.

That sort of thing simply isn't possible with Ext4.

[flower]

I want to switch to bcachefs but the lack of subvolume mounts is holding me back.

I really dont understand the problem with bind mounts.

yes it is more convenient to be able to mount them directly. but -to me - it would never be the reason to not use a specific filesystem.

but well... i guess you just have to wait until that's implemented.

[Anux]

That sort of thing simply isn't possible with Ext4.

rsync begs to differ.

[AdrianBc]

ext4 and XFS are fast and all... but, how do you all live without hourly snapshots?

They saved my life so many times that I cannot think about working without them 🙂

I do not know about EXT4, but nowadays XFS also provides snapshots and copying any files on XFS does copy-on-write, so the initial copy is instantaneous even for a terabyte file.

Because XFS has added snapshots relatively recently, other file systems might have more convenient utilities for that, but nobody stops an XFS user to write a script that takes hourly snapshots of the file system (by invoking xfsdump).

[AdrianBc]

Coping hard?

Btrfs is 15 years old, while bcachefs has been field tested for less than a year. If anything, it's the latter that has room for optimizations and I'm pretty sure it's gonna get faster still.



I've never seen NTFS or ext4 corrupt in my entire life (since mid 90s), yet no FS is safe from hardware failure. So backups are essential no matter what.

Perhaps in the latest Windows versions NTFS has become more reliable, even if it has remained very slow.

On the other hand, in Windows XP it was very easy to corrupt NTFS with power failures, despite the journaling. Moreover, in such older NTFS versions even if no failures happened, the free space on the HDD was decreasing constantly, even if the space occupied by the user files was constant. In some cases it was necessary to reformat the HDD and reinstall Windows XP after a few months, in order to get again enough free space (this bug has been corrected by one of the many service packs released by Microsoft, a few years after the Windows XP launch).

To be fair, at the time when Windows XP was in use, all the Linux file systems, including XFS and EXT3, were also easily corruptible by power failures, despite the journaling (in XFS the metadata was not corrupted, but XFS cleared the files that were open before the failure, even if they were open only for read; this bricked the computer, typically by clearing /etc/fstab).

At that time, the FreeBSD UFS with "soft updates" was the only widespread file system that was completely immune to corruption after a power failure.

Many years later, XFS has corrected its defects and this year I have seen a few power failures in the middle of intense SSD and HDD activity on XFS, which did not result in any data corruption (for any modified files, I always update content hashes in extended file attributes, to check for data corruption at any time).

I suppose that nowadays EXT4 is similarly robust.

[mdedetrich]

My point that you seem to have missed is that maybe bcachefs needs workarounds and code changes that will slow down the filesystem as bugs are discovered and race conditions are found. I hope not, but that may happen. It is a rather fresh filesystem so lots of unknowns are possible.

There are less chances of this happening with bcachefs as unlike btrfs, the developer tried as much as possible to get the original design "right" where as btrfs was to a certain extent rushed out for various non technical reasons.

bcachefs sat out of the Linux kernel tree for more than half a decade (iirc) before Kent felt comfortable merging it into the Linux kernel.

[mdedetrich]

For users of personal computers, with limited budgets and computer sizes, there are two file systems with real time compression included. Commercial NTFS and btrfs.

You missed zfs on that list

[StarterX4]

I recently switched from using multiple Btrfs partitions to an LVM2-based F2FS(root)+XFS(virtual machines+LUKS2&Ext4(/home)+Btrfs(Steam+games) scheme, and I consider it one of the best I ever had in years.