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

[waxhead]

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.

I completely disagree. The chances for this happening are 100% and nobody knows how complex unknowns are. I have no doubts that Kent tried to do things right, but nobody is perfect and neither is Kent. As for the chance of bcachefs having less unknowns that needs to be dealt with? That is something that nobody knows (since it is unknowns) and only time will tell if Kent did a better design or not.

BTRFS is far from perfect either, and the biggest problem is in my opinion that they used the RAID terminology. While it is close enough for many things it differs radically from regular RAID. For example most people believe that RAID1 is a mirror. In BTRFS the second device is NOT a mirror of the first. It may contain the same data yes, but it is not a mirror. And as far as RAID5/6 goes it is a complete and utter fiasco in my personal opinion and is actually RMW instead of COW. The raid stripe tree will hopefully fix that once and for all and RAID5/6 will become useful.

Personally I have nothing against BcacheFS at all, I actually welcome it and perhaps one day I'll switch from BTRFS to BcacheFS if it turns out to be that much better. And honestly I hope the projects learn from each other or maybe even merges into a single project.

[duby229]

rsync begs to differ.

THIS^^^

I'm wondering how many of these guys know what bash is? Have these guys ever heard of a shell? Do they even know the most basic shell tools?

I think that is who BTRFS is for, people who have no fucking clue what they are actually doing.

[waxhead]

THIS^^^

I'm wondering how many of these guys know what bash is? Have these guys ever heard of a shell? Do they even know the most basic shell tools?

I think that is who BTRFS is for, people who have no fucking clue what they are actually doing.

For your information BTRFS has something called send/receive which is quite different and beneficial over rsync for certain tasks. Apparently you lack the understanding of the very thing you are criticizing BTRFS users for.

[varikonniemi]

I completely disagree. The chances for this happening are 100% and nobody knows how complex unknowns are. I have no doubts that Kent tried to do things right, but nobody is perfect and neither is Kent. As for the chance of bcachefs having less unknowns that needs to be dealt with? That is something that nobody knows (since it is unknowns) and only time will tell if Kent did a better design or not.

BTRFS is far from perfect either, and the biggest problem is in my opinion that they used the RAID terminology. While it is close enough for many things it differs radically from regular RAID. For example most people believe that RAID1 is a mirror. In BTRFS the second device is NOT a mirror of the first. It may contain the same data yes, but it is not a mirror. And as far as RAID5/6 goes it is a complete and utter fiasco in my personal opinion and is actually RMW instead of COW. The raid stripe tree will hopefully fix that once and for all and RAID5/6 will become useful.

Personally I have nothing against BcacheFS at all, I actually welcome it and perhaps one day I'll switch from BTRFS to BcacheFS if it turns out to be that much better. And honestly I hope the projects learn from each other or maybe even merges into a single project.

bcachefs is close to having full self healing capabilities, so data loss would be extremely hard to achieve. Meaning that you can nuke anything that has with the filesystem's data structures to do, and fsck will rebuild it. Worst case scenario is that you need to scan the whole disk from start to finish, but it's pretty impossible to hit since the actual data structures, and the bitmaps in the superblocks would need to be damaged for that to be necessary.

To this day not one irrecoverable data loss event has happened since it was merged. And Kent is dedicated to keep it that way. You see, it's the filesystem that won't eat your data

[DumbFsck]

Unless your day-to-day workflow resembles a stress test, you'll be unlikely to notice any meaningful performance differences between Ext4 and Btrfs.

This is only a half Truth. There are quite a few normal day to day things/tasks that end up being more similar to a strwas test.

One example of a situation where I do notice the lack of performance in my btrfs disks is game installation, I have a <Gigabit Internet at home, but still, it gets enough data fast enough, and this data is compressed enough and current CPUs are fast enough that the bottleneck in my system is it's IO performance. And tbqh my ssd isn't slow either. I don't know if my btrfs is also compressed, what I know is that steam is particularly bad in that I can limit the download speed but not limit CPU usage, so I get full system lag at points in the installation.


I'm still happy to use it and it was part of one of the reasons I even chose my distro (OpenSUSE tumbleweed). But it is noticeable.

[jstoik]

This is only a half Truth. There are quite a few normal day to day things/tasks that end up being more similar to a strwas test.

That's why I opened that reply with "Unless your day-to-day workflow resembles a stress test…"

In fact for a game like City Skylines, I'd go even further and suggest stress tests resemble them. Haha.

[blackiwid]

And here come the excuses for btrfs and bcachefs performance. First up: Their 'by-design' COW is part of it.

Well ZFS is also much slower than Ext4 are the ZFS users than also only blaming COW or do they just pretend they are faster than ext4

Overall, except for application launch time, benchmark results show that ZFS is the slowest file system in terms of read and write speed due to its COW operating type, while EXT4 is usually the fastest system.

https://digitalmasta.com/10712-zfs-vs-ext4-vs-btrfs-best-file-system-for-nas/

Here is so much "now the people that say that the flat is earth and dinos still live come" strawm+en Bullshit, I bet most BTRFS people are not married to BTRFS if BcacheFS is trustworthy enough and has enough features for people and it's faster than btrfs than people have no problem to switch.

The real fanatics are the ZFS people they are married to that Filesystem, people that prefer BTRFS mostly are Linux people and maybe certain licenses or free software. Most of us are probably not extremely big fans of btrfs but more haters towards ZFS, because we don't like Userspace filesystems, and we don't like certain companies and developer think they are more important than linux and can force to either Linux use a different license or just ignore their license to help them to be integrated.

[cynic]

rsync begs to differ.

you cannot make a consistent rsync of your system unless you stop all the services (basically you have to mount ro with a live)

With btrfs you have atomic snapshot and send/receive to backup to external storage.

[waxhead]

bcachefs is close to having full self healing capabilities, so data loss would be extremely hard to achieve. Meaning that you can nuke anything that has with the filesystem's data structures to do, and fsck will rebuild it. Worst case scenario is that you need to scan the whole disk from start to finish, but it's pretty impossible to hit since the actual data structures, and the bitmaps in the superblocks would need to be damaged for that to be necessary.

To this day not one irrecoverable data loss event has happened since it was merged. And Kent is dedicated to keep it that way. You see, it's the filesystem that won't eat your data

If you remove all metadata I am sure bcachefs would not work. Anyway, believe what you want - filesystems do sooner or later fail. No matter if it is BTRFS, ZFS or even BcacheFS.

[User29]

Unfortunately CachyOS recently dropped GNOME, and since I use XFCE which is highly dependent on GNOME I had to revert my desktop system to Arch and convert my ZFS disks to BTRFS.

And wow, BTRFS is not only palpably slower, but when copying terabytes of data to my BTRFS disks my system would actually freeze for around 15 seconds every few minutes. And this is without any fancy features like compression.

This was quite disturbing, and now I really don't know what to do. I also have a media server with 48 TB of disks, which are about 70% full, and I'm really worried about how BTRFS will perform with such a massive amount of data. I wish the CachyOS devs would let its users know for certain if dropping GNOME is going to affect XFCE, which I expect it will, but so far I haven't received a clear answer.

So I'm in a holding pattern waiting to find out before reverting my media server to Arch, as it will take an extraordinary amount of work and time. All I need is a reasonably fast filesystem with data integrity verification, and the ability to use XFCE. But CachyOS really dropped a bomb on its users, and are going all in on KDE and Wayland for some reason. And while some people like Windows type DEs like KDE and GNOME, I will never abandon the elegant simplicity and efficiency of XFCE.

not joking, but did you consider FBSD on your media server?

it's a bit old fashioned but simple as a nail and does have ZFS by default.