Btrfs Sends In Fixes For Linux 6.10 & Restores "norecovery" Mount Option

[phoronix]

Phoronix: Btrfs Sends In Fixes For Linux 6.10 & Restores "norecovery" Mount Option

Last week saw the main Btrfs pull request for Linux 6.10 that delivered on some performance optimizations while today saw a secondary set of merge window changes for this CoW file-system that is now adding back the "norecovery" mount option...

https://www.phoronix.com/news/Btrfs-norecovery-Linux-6.10

[EphemeralEft]

The moral of the story is that if your project is popular enough, upstream ensures compatibility with you.

3 years of deprecation is more than enough time for developers to fix their projects; this just sets a bad precedent.

[cynic]

It was Lennart Pottering asking for the revert, for systemd features

https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/

[NekkoDroid]

3 years of deprecation is more than enough time for developers to fix their projects; this just sets a bad precedent.

The problem with this is the kernels "we don't break userspace" promise. And reading millions of lines of logs to check for a deprecation warning is just not realistic.

And the thing they changed apparently is effectivly just renaming the option under a different name, while the other filesystems use the old name for the same feature.

[AlanTuring69]

The moral of the story is that if your project is popular enough, upstream ensures compatibility with you.

3 years of deprecation is more than enough time for developers to fix their projects; this just sets a bad precedent.

nope, its not like this is some major feature or cleanup, its just a random command line option. if you dont appropriately run a campaign and want people to actually use your software for years to come, you need to make sure you arent unreasonable with breaking backwards compatibility. if its some random flag then just maintain its functionality as a thin shim, as they've done here. otherwise you will have devs come in and ask "why the fuck did they randomly change the command line option?" and then documentation from years past stops working, and people ragequit off of btrfs

[cynic]

nope, its not like this is some major feature or cleanup, its just a random command line option. if you dont appropriately run a campaign and want people to actually use your software for years to come, you need to make sure you arent unreasonable with breaking backwards compatibility. if its some random flag then just maintain its functionality as a thin shim, as they've done here. otherwise you will have devs come in and ask "why the fuck did they randomly change the command line option?" and then documentation from years past stops working, and people ragequit off of btrfs

I wouldn't necessarily look for someone to blame for what happened.

I do agree with what you wrote, but at the same time, the deprecation was annouced 3 years ago, that look like a fairly reasonable time for every users to raise his hand to stop the process.

At the end, as soon as the problem was discovered, it was quickly and cooperatively fixed.

[timofonic]

It was Lennart Pottering asking for the revert, for systemd features

https://lore.kernel.org/linux-btrfs/...@gardel-login/

All this is very weird. Why was deprecated? Why was changed to other name? What about non-Btrfs filesystems too? What if wanting to use the same systemd feature on non-Btrfs filesystems?

Can someone please explain this to us mere mortals? It's very weird for me

Thanks in advance!

[AlanTuring69]

I wouldn't necessarily look for someone to blame for what happened.

I do agree with what you wrote, but at the same time, the deprecation was annouced 3 years ago, that look like a fairly reasonable time for every users to raise his hand to stop the process.

At the end, as soon as the problem was discovered, it was quickly and cooperatively fixed.

not saying that someone is to blame. just arguing that breaking command line flags is one of the least likely-to-be-noticed breakages and just releasing an update with a warning isn't enough especially for something as widespread as btrfs.

[EphemeralEft]

not saying that someone is to blame. just arguing that breaking command line flags is one of the least likely-to-be-noticed breakages and just releasing an update with a warning isn't enough especially for something as widespread as btrfs.

It's not a command line flag, it's a mount option. Those can be specified via command line flags with the user-space mount utility, but that's just one way mounts can be manipulated. For example, systemd is almost certainly using system calls to manipulate mounts.

I'm pretty sure using the deprecated option printed a warning in dmesg, which developers definitely should have noticed after 3 years.

[waxhead]

Well if the kernel can deprecate drivers and make a.out obsolete which definitively breaks userspace then this is not such a big deal I think. In any case it was easily solved.
The BTRFS devs tried to clean up what has become a mess by removing redundant mount options since the functionality is also available via the rescue mount option which gives better fine grained control over what to do or not do. Good intentions are not always appreciated it seems