Linux 5.16.5 Released To Fix Up Btrfs' Botched Up Defragging

[pkese]

Mind that I never used BTRFS outside a VM (where I never had problems with it) and mostly read the bad news about it like the broken Raid 5/6 or a missing repair tool, those hopefully got fixed now? All this time I can remember one thing with ext4 that really wasn't a bug in ext4 but how Toolkits/DEs used it.
Reading bad things about a filesystem whos main purpose is to savely store your files, creates a certain fear. If MDADM had a problem currupting files it would also get blown up and create fear of using it in production.
Maybe BTRFS is now a flawless filesystem but it has lost trust and now everyone is looking for the tinyest thing because of its troubled history.

Mind that you never had problems with btrfs but you are using the vocabulary like "broken raid 5/6", "corrupting files", etc.

MD-raid had the exact same raid write hole issue until about 2017-2018 (and yes, people were losing data), yet somehow all the dramatization about write hole problem were always related to btrfs, never to MD-raid. Same problem, same statistics, yet people reacted differently due to different expectations.

There's nothing per-se wong with btrfs. It is a well designed and extremely safe filesystem. Most of the excessive btrfs bug reports are not due to btrfs issues but rather due to the fact that unlike other filesystems, brtfs is constantly doing data checksuming at every read and detecting data errors which would go unnoticed on other filesystems.

Then it's for people to decide, if they prefer filesystems that silently corrupt their data for years, or a filesystem that whines about that on every encounter. If you're in the first category (or like overclocking your CPU and memory), then yes, probably you should stay away from btrfs.

Overall I'm considering the btrfs drama similar to systemd: both are technically superior solutions to what Linux had before, yet people tend to get very dramatic around them.

[cynic]

It puzzles me that people can't recall serious bugs in other filesystems (you Just have to go openzfs' issue tracker in github, for example). ext4 and XFS had data eating bugs in the past when they were already "production ready" (zero-byte files after unclean umount amuses anyone?).

the zeroing of files hitted me so many times with XFS that I stopped using it, even if I know that now it's fixed.
still, i don't bash XFS on every news on Phoronix, as some people do with btrfs.

[Volta]

Reputation should reflect the quality. If there are regular regressions, it should affect the reputation, not just of a single fs but for the kernel on the whole. The goal should to push for more quality control - automated tests and so forth rather than hide the problem.

When comes to regressions you could reconsider changing the default CPU governor in Fedora. I couldn't figure out why my games started working like a POS till I saw a benchmark at Phoronix regarding CPU governors. After switching from currently terribly broken schedutils to ondemand (performance is even better of course) everything started working flawlessly like before. Even games like Quake Live and Terraria suffer from schedutils. 7days to die was unplayable. Now it works perfectly.

[RahulSundaram]

When comes to regressions you could reconsider changing the default CPU governor in Fedora

I am not involved there at all. You can post in the Fedora kernel list and ask however.

[mdedetrich]

Mind that you never had problems with btrfs but you are using the vocabulary like "broken raid 5/6", "corrupting files", etc.

MD-raid had the exact same raid write hole issue until about 2017-2018 (and yes, people were losing data), yet somehow all the dramatization about write hole problem were always related to btrfs, never to MD-raid. Same problem, same statistics, yet people reacted differently due to different expectations.

There's nothing per-se wong with btrfs. It is a well designed and extremely safe filesystem. Most of the excessive btrfs bug reports are not due to btrfs issues but rather due to the fact that unlike other filesystems, brtfs is constantly doing data checksuming at every read and detecting data errors which would go unnoticed on other filesystems.

Then it's for people to decide, if they prefer filesystems that silently corrupt their data for years, or a filesystem that whines about that on every encounter. If you're in the first category (or like overclocking your CPU and memory), then yes, probably you should stay away from btrfs.

Overall I'm considering the btrfs drama similar to systemd: both are technically superior solutions to what Linux had before, yet people tend to get very dramatic around them.

I am sorry but you are deceptively rephrasing things to absolve responsibility for btrfs's shortcomings.

For starters comparing it to older filesystems or RAID systems like mdadm is besides the point because these were never ones that was designed (and most importantly advertised) as CoW filesystems that were ultra safe. I mean mdadm is ancient and back in those days most serious users of RAID used hardware RAID controllers exactly because of how unreliable the software of these systems were.

If you want to make a legitimate comparison for BTRFs than compare it to ZFS which in respect to actual reliability of your data is miles ahead of BTRFs and is also older (which is quite ironic). In fact technically speaking ZFS is so much better than BTRFs in this regard that distro's will open themselves up to legal repercussions to include it.

I am sorry but this is another item on a bucketlist of reasons why I would never touch BTRFs with a ten foot pole for any serious data storage unless I happen to use the exact configuration that someone like facebook uses (which is probably some basic mirrored RAID10). At least with ZFS I know that if some new feature is merged into the main release it doesn't cause catastrophically embarrassing issues like this one.

[oleid]

At least with ZFS I know that if some new feature is merged into the main release it doesn't cause catastrophically embarrassing issues like this one.

How do you know that?

• disappearing files and unlistable directories https://github.com/openzfs/zfs/issues/7401
• sendfile doesn't work anymore (lots of software relies on that) https://github.com/openzfs/zfs/issues/12971
• files lost after ubuntu upgrade https://askubuntu.com/questions/1285...e-to-20-04-lts

Just a two minute search, I'm pretty sure there is more.

Actually, the issues on their tracker sound quite scary:

https://github.com/openzfs/zfs/issues

• Denial-of-service lockup in txg_sync when several raw recvs happen at once
• Kernel oops on zfs create, or later when copying files
• Kernel panic at zpool import time
• Very slow recursive deletion of many snapshots
• Setting spl_kmem_cache_slab_limit higher than 16384 makes the magic smoke come out
• import -f hangs, import -f -o readonly=on works
• zed writing to pool disks (a lot) for 20+ minutes on reboot
• Unending numbers of checksum errors sometimes
• Crash under IO load when using both encryption and deduplication

I stopped on the 2nd page of issues, 905 issues are open.So I'm asking again, how do you know that?

[mdedetrich]

How do you know that?

• disappearing files and unlistable directories https://github.com/openzfs/zfs/issues/7401
• sendfile doesn't work anymore (lots of software relies on that) https://github.com/openzfs/zfs/issues/12971
• files lost after ubuntu upgrade https://askubuntu.com/questions/1285...e-to-20-04-lts

Just a two minute search, I'm pretty sure there is more.

Actually, the issues on their tracker sound quite scary:

https://github.com/openzfs/zfs/issues

• Denial-of-service lockup in txg_sync when several raw recvs happen at once
• Kernel oops on zfs create, or later when copying files
• Kernel panic at zpool import time
• Very slow recursive deletion of many snapshots
• Setting spl_kmem_cache_slab_limit higher than 16384 makes the magic smoke come out
• import -f hangs, import -f -o readonly=on works
• zed writing to pool disks (a lot) for 20+ minutes on reboot
• Unending numbers of checksum errors sometimes
• Crash under IO load when using both encryption and deduplication

I stopped on the 2nd page of issues, 905 issues are open.So I'm asking again, how do you know that?

Did you even read the issues you posted?

I just wasted 3 minutes of my time reading the first one and it turned out to be a centos/REHL issue with outdated kernels on Linux i.e. https://github.com/openzfs/zfs/issue...ment-379550690.

Maybe spend a more cohesive effort into substantiating your argument rather than just browsing the issues page on the project.

[reba]

Rust-implemented filesystem - when?

Not meant as start of a flame war, but the language would be a good fit IMHO: statically compiled, no buffer under-/overruns, easily parallelizable for very high IOPS, ...
What do you think? Seriuos discussion only, please.

[oleid]

Did you even read the issues you posted?

I just wasted 3 minutes of my time reading the first one and it turned out to be a centos/REHL issue with outdated kernels

That bug is from already closed and is an older one. But it was big in the news back then.
The point is: how can you be sure you're not hit by a bug in the future given they already happened. The point is you can make a bucket list of reasons you won't touch filesystem XYZ based on fixed bugs no matter what filesystem you choose. And you cannot be sure that zfs will not get issues like this one in future. Period.

[intelfx]

Don't think it needs any help there 😉 admittedly I'm no expert on brtfs, but from what I have read/heard, I do wonder how it lost its experimental/unstable flag. The whole architecture sounds flawed.

So, you're "no expert on btrfs", but you feel qualified to make judgement claims on its architecture?