Btrfs Slated To Make Use Of New Mount API In Linux 6.8

[phoronix]

Phoronix: Btrfs Slated To Make Use Of New Mount API In Linux 6.8

Coming up for the Linux 6.8 kernel the Btrfs file-system is preparing to make use of the newer Linux file-system mounting API...

https://www.phoronix.com/news/Btrfs-New-Mount-API-Linux-6.8

[timofonic]

Slow adoption? I wonder what's more left...

[royce]

Good stuff.

[geearf]

What's the benefit for users of btrfs? I've skimmed the video but didn't get it.

[WileEPyote]

What's the benefit for users of btrfs? I've skimmed the video but didn't get it.

Joined just to find this out. Switched to btrfs a while back because of the easy integration with Windows, and then bought a Steam Deck which pretty much cemented my decision. My only complaint is it's lack of performance compared to ext4. Will this help in that area, better security? What's the benefit for us end users?

[evert_mouw]

Joined just to find this out. Switched to btrfs a while back because of the easy integration with Windows, and then bought a Steam Deck which pretty much cemented my decision. My only complaint is it's lack of performance compared to ext4. Will this help in that area, better security? What's the benefit for us end users?

Why not use exfat when the partition must be shared between Windows and Linux?

[muncrief]

Good god, after the latest ZFS disaster I'm no longer trying any new features on any file systems until they've been long tested in the real world. As I posted on the "OpenZFS Is Still Battling A Data Corruption Issue" thread recently, perusing the ZFS and BTRFS developer threads is positively frightening as it's obvious no one really knows exactly what's going on. And there's a simple and preventable reason for it - there are no all encompassing architectural documents, specifications, or coverage and fuzz verification suites, for either file system. Instead everyone is just throwing code in and running arbitrary scripts to "prove" the code works.

By the way, the Arch AUR zfs-dkms package backported the (cross your fingers) fix for the ZFS corruption issue yesterday. They patched the released 2.2.1 code with "https://github.com/openzfs/zfs/commit/30d581121bb122c90959658e7b28b1672d342897.patch"

I'd already patched and built my own zfs-dkms with this patch a few days ago and haven't had any obvious problems, but since the issue is silent data corruption, and there are no real guides or verification test suites, it's anyone's guess as to whether or not the problem has really been solved.

In any case best of luck to the ZFS and BTRFS development teams, and I hope they will heed the advice I lent on the other thread. I greatly appreciate all their hard work, but wow, they all really need to step back and develop the basic specifications, documents, and test suites they should have created in the first place.

[discordian]

Why not use exfat when the partition must be shared between Windows and Linux?

no checksums. with WinBtrfs you can just use it like an exfat partition in windows

[discordian]

Joined just to find this out. Switched to btrfs a while back because of the easy integration with Windows, and then bought a Steam Deck which pretty much cemented my decision. My only complaint is it's lack of performance compared to ext4. Will this help in that area, better security? What's the benefit for us end users?

you won't see a difference, perhaps in the future some complicated mount commands will only be possible with filesystems using the new api.

[evert_mouw]

no checksums. with WinBtrfs you can just use it like an exfat partition in windows

that's a good reason indeed, although exfat is easier (and Mac's also can access exfat)
but agreed, checksumming is good, I use zfs for important data, exfat is just a toy