On Thu, May 04, 2023 at 02:07:07PM -0300, Guilherme G. Piccoli wrote: > Btrfs doesn't currently support to mount 2 different devices holding the > same filesystem - the fsid is used as a unique identifier in the driver. > This case is supported though in some other common filesystems, like > ext4; one of the reasons for which is not trivial supporting this case > on btrfs is due to its multi-device filesystem nature, native RAID, etc. > > Supporting the same-fsid mounts has the advantage of allowing btrfs to > be used in A/B partitioned devices, like mobile phones or the Steam Deck > for example. Without this support, it's not safe for users to keep the > same "image version" in both A and B partitions, a setup that is quite > common for development, for example. Also, as a big bonus, it allows fs > integrity check based on block devices for RO devices (whereas currently > it is required that both have different fsid, breaking the block device > hash comparison). > > Such same-fsid mounting is hereby added through the usage of the > mount option "virtual_fsid" - when such option is used, btrfs generates > a random fsid for the filesystem and leverages the metadata_uuid > infrastructure (introduced by [0]) to enable the usage of this secondary > virtual fsid. But differently from the regular metadata_uuid flag, this > is not written into the disk superblock - effectively, this is a spoofed > fsid approach that enables the same filesystem in different devices to > appear as different filesystems to btrfs on runtime. Have you evaluated if the metadata_uuid could be used for that? It is stored on the filesystem image, but could you adapt the usecase to set the UUID before mount manually (in tooling)? The metadata_uuid is lightweight and meant to change the appearance of the fs regarding uuids, verly close to what you describe. Adding yet another uuid does not seem right so I'm first asking if and in what way the metadata_uuid could be extended.
