About duplicate fsid images in different devices

About duplicate fsid images in different devices

[Guilherme G. Piccoli]

Hi btrfs maintainers, I'd like to discuss about the possibility of
having btrfs allowing to mount any of a set of different devices holding
the same filesystem, i.e, a duplicate fsid scenario. For example,
imagine sda1 and sdb1 both contains the same filesystem, I'd like to be
able to mount either sda1 OR sdb1 (not both at the same time!);
currently, only the first that was created is able to get mounted.

First of all, let me describe the use case I have in mind: the Steam
Deck gaming console makes use of an A/B double side partitioning scheme
and a RO btrfs rootfs is one of the partitions (in each "side"). So, we
could have a scenario of some user that wishes to have the same image in
both "sides", perhaps to test some modifications for example and have
the pristine/unmodified image in the other one. Before using btrfs,
Steam Deck was using ext4 and everything worked fine in such scenario,
but with btrfs it's impossible to (even explicitly) mount the newer
partition with the same fsid. We also have the use case of images'
upgrading process, that in a recovery configuration might end-up
installing the same (pristine) image in the other "side"; that case is
kinda trivial one that we'd expect to work. Notice that a reason behind
this duplication in the images' fsid is because they're signed rootfs
snapshots, so wouldn't so trivial/desirable to de-duplicate them in some
cases.

By checking the code, we can see that the validations preventing such
mounting operation happens in device_list_add(): when udevd checks the
filesystems on boot time, the older partition (the first one with the
given fsid) is verified and the btrfs_fs_devices struct is null - hence
it is created along with the corresponding btrfs_device for such
partition/device, which is added in the fs_devices list. When the newer
partition gets scanned, fs_devices exists, so the function
btrfs_find_device() is invoked and finds the first btrfs_device, which
differs from the one we are trying to mount, effectively leading to this
second device being impossible to mount.

Since I'm not an expert in the btrfs inner workings, I'd like some
advice to understand if some mount flag would be accepted to enable this
behavior; maybe I'm not seeing some subtle issue, but given the 2-side
nature of our setup, the explicit mount point control, and the fact we
don't expect to use any btrfs more "complex"features that might be
confused by non-unique fsids (like RAID), seems feasible to allow such
btrfs behavior. Notice we don't require to change the default, hence the
idea to have it as a mount flag or something like that - suggestions are
greatly appreciated.

Thanks in advance,


Guilherme

Re: About duplicate fsid images in different devices

[Guilherme G. Piccoli]

On 16/11/2022 16:04, Torstein Eide wrote:
> Hi Guilherme
> ## Have you tried changing volumes instead of the partition?
> https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html
> <https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html>
> 
> ## Given that  SteamOS does not change much between updates. 
> Maybe look in to union Filesystem, like docker uses:
> https://martinheinz.dev/blog/44 <https://martinheinz.dev/blog/44>
> https://gdevillele.github.io/engine/userguide/storagedriver/btrfs-driver/ <https://gdevillele.github.io/engine/userguide/storagedriver/btrfs-driver/>
> 
> ## Alternativ 2 The use of snapshots of the OS partition/subvolume, like
> snapper:
> https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html#subvolume-and-snapshot <https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html#subvolume-and-snapshot>
> https://wiki.archlinux.org/title/snapper
> <https://wiki.archlinux.org/title/snapper>
> 
> 
> -- 
> Torstein Eide
> Torsteine@gmail.com <mailto:Torsteine@gmail.com>

Thank you Torstein! I'm not sure snapshot or Union filesystem approaches
would help - we just want a RO fs and be able to mount any of two
identical partitions (with the same fs/fsid) on btrfs. It doesn't work
in btrfs but it's fine on ext4. We could try improving the code with a
mount option, but this email to collect opinions if that would harm some
fundamental principle in btrfs and, indeed, would be unacceptable.

Cheers,


Guilherme