On 2023/5/8 19:27, Anand Jain wrote:
On 05/05/2023 21:38, David Sterba wrote:
On Fri, May 05, 2023 at 03:21:35PM +0800, Qu Wenruo wrote:
On 2023/5/5 01:07, 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.
Exactly, the biggest problem is the multi-device support.
Btrfs needs to search and assemble all devices of a multi-device
filesystem, which is normally handled by things like LVM/DMraid, thus
other traditional fses won't need to bother that.
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.
I would prefer a much simpler but more explicit method.
Just introduce a new compat_ro feature, maybe call it SINGLE_DEV.
By this, we can avoid multiple meanings of the same super member, nor
need any special mount option.
Remember, mount option is never a good way to enable/disable a new
feature.
The better method to enable/disable a feature should be mkfs and
btrfstune.
Then go mostly the same of your patch, but maybe with something extra:
- Disbale multi-dev code
Include device add/replace/removal, this is already done in your
patch.
- Completely skip device scanning
I see no reason to keep btrfs with SINGLE_DEV feature to be added to
the device list at all.
It only needs to be scanned at mount time, and never be kept in the
in-memory device list.
This is actually a good point, we can do that already. As a conterpart
to 5f58d783fd7823 ("btrfs: free device in btrfs_close_devices for a
single device filesystem") that drops single device from the list,
single fs devices wouldn't be added to the list but some checks could be
still done like superblock validation for eventual error reporting.
Something similar occurred to me earlier. However, even for a single
device, we need to perform the scan because there may be an unfinished
replace target from a previous reboot, or a sprout Btrfs filesystem may
have a single seed device. If we were to make an exception for replace
targets and seed devices, it would only complicate the scan logic, which
goes against our attempt to simplify it.
If we go SINGLE_DEV compat_ro flags, then no such problem at all, we can
easily reject any multi-dev features from such SINGLE_DEV fs.
Thanks,
Qu
Thanks, Anand
