Subvolumes and such require a kernel to be loaded in order to use, so that’s why the base device partitions don’t run that way.
That’s a great point I never thought about. I really wondered why they wouldn’t go with btrfs subvolumes, since they could easily btrfs send and receive subvols like they do now with whole partitions. Subvols would even have the benefit of less space needed since many files probably stay the same between updates.
My guess was that the update mechanism used doesn’t support btrfs, though after a quick search on the rauc github it might actually support it.
Pretty much every Linux bootloader supports BTRFS these days.
The critical thing though, is that happens if your BTRFS partition gets corrupted? You just lost your failover since both your primary and failover are on the same partition.
That’s fine on a desktop system where the user can boot into a recovery image and repair the filesystem, but it’s not fine when you do a completely automated system upgrade. So for a kiosk, console, or other embedded system, the two partition setup is more reliable than a BTRFS root with subvolumes.
Possibly because of better reliability. If a filesystem breaks, all subvolumes it contains break in turn. Whereas independent filesystems will continue to run if one is corrupted.
I wonder why they use A/B root in the first place instead of a single BTRFS partition with Subvolumes and snapshots
Removed by mod
That’s a great point I never thought about. I really wondered why they wouldn’t go with btrfs subvolumes, since they could easily btrfs send and receive subvols like they do now with whole partitions. Subvols would even have the benefit of less space needed since many files probably stay the same between updates.
My guess was that the update mechanism used doesn’t support btrfs, though after a quick search on the rauc github it might actually support it.
steamos-teardown is a great project to learn more about SteamOS, btw. https://github.com/77Z/steamos-teardown
Pretty much every Linux bootloader supports BTRFS these days.
The critical thing though, is that happens if your BTRFS partition gets corrupted? You just lost your failover since both your primary and failover are on the same partition.
That’s fine on a desktop system where the user can boot into a recovery image and repair the filesystem, but it’s not fine when you do a completely automated system upgrade. So for a kiosk, console, or other embedded system, the two partition setup is more reliable than a BTRFS root with subvolumes.
Possibly because of better reliability. If a filesystem breaks, all subvolumes it contains break in turn. Whereas independent filesystems will continue to run if one is corrupted.