The functionality is to overcome a limitation of allowing Btrfs to mount two different devices holding the same file-system image and therefore the same file-system ID.
Will enable A/B partitioning with the same image.
This is good for stream deck, but also phones, embedded devices like routers, and I imagine some (future?) immutable distros that choose to do A/B like Vanilla OS.
Maybe we’ll finally see btrfs with compression on the Deck by default. This might help a bit with the storage issues on the 64GB Deck.
The only other thing that I know also is needed is case folding
If there are other features needed I don’t know about them
I really love the current trend in R&D PowerPoints
- generic text
- problem: x doesn’t work
- solution: do something so x works
- some contributor list/thanks
Removed by mod
Release notes, innit? For a very technical new feature; that seems enough. If it was a bug, then maybe a line about how we missed it; if it’s user facing, what new functionality it enables. You can always go look at the PR if you want the real detail.
Missed opportunity for a Linux version 6.6.6
6.6.0 isn’t out yet, but it’s pretty likely that there will be a 6.6.6 in the next few months.
Oh good. Linus seems like the kind of dude that wouldn’t skip a landmark release.
I know people are obviiusly waiting for 6.9 as well
Honestly though, skipping it because of its cultural/religious connotations opens up a bad can of worms, because it’s not the only shunned number, and it varies from culture to culture, and you can’t really give preferential treatment to one culture over any other, as a global mainstream project like this.
Linux specifically broke versioning standards so that we could have 3.11 (windows) and 4.20 (weed). It should be fine.
This is the best summary I could come up with:
Queued up into the Btrfs file-system driver’s “for-next” branch ahead of the Linux 6.7 cycle is the Temp-FSID (Same-FSID) feature that is being pursued for use by Valve’s Steam Deck game console.
Such same-fsid mounting is hereby added through the usage of the filesystem feature “temp-fsid” - when such feature is used, btrfs generates a random fsid for the filesystem and leverages the long-term present metadata_uuid infrastructure to enable the usage of this secondary “virtual” fsid, effectively requiring few non-invasive changes to the code and no new potential corner cases.
In order to prevent more code complexity and corner cases, the temp-fsid feature is not allowed when the metadata_uuid flag is present on the fs, or if the device is on fsid-change state.
This functionality has been queued into kdave/linux.git’s for-next branch where Btrfs material is staged ahead of the next Linux kernel cycle.
Thus this new Btrfs feature will be found in Linux 6.7 barring any issues from appearing between now and the merge window opening around early November.
This Btrfs feature was also mentioned last week at OSS EU 2023 as part of Valve’s upstream contributions to Linux.
The original article contains 462 words, the summary contains 190 words. Saved 59%. I’m a bot and I’m open source!
This is pretty cool, but I’m wondering why… Sure there’s lots of systems that make use of A/B partitions, which is a pretty good move, but with BTRFS you could have it all in one partition with an A/B subvolume, and they would even be able to share extents that are common between the two (meaning drastically reduced disk space requirements), while still maintaining the ability to boot into either…
Depending on how much changes you might even keep many more than just two subvolumes. On my machine I run BTRFS with snapper, which takes periodic snapshots, as well as before and after every time I install or uninstall a package, with the ability to boot into any of the snapshots if a change somehow botches my system.
