On 19/09/2023 02:01, Anand Jain wrote: > [...] > This must successfully pass the remaining Btrfs fstests test cases with > the MKFS_OPTION="-O temp-fsid" configuration option, or it should call > not run for the incompatible feature. > I kinda disagree here - this feature is not compatible with anything else, so I don't think it's fair to expect mounting with temp-fsid will just pass all other tests, specially for things like (the real) metadata_uuid or extra devices, like device removal... > I have observed that the following test case is failing with this patch: > > $ mkfs.btrfs -fq /dev/sdb1 :0 > $ btrfstune --convert-to-temp-fsid /dev/sdb1 :0 > $ mount /dev/sdb1 /btrfs :0 > > Mount /dev/sdb1 again at a different mount point and look for the copied > file 'messages': > > $ cp /var/log/messages /btrfs :0 > > $ mount /dev/sdb1 /btrfs1 :0 > $ ls -l /btrfs1 :0 > total 0 <-- empty > > The copied file is missing because we consider each mount as a new fsid. > This means subvolume mounts are also not working. Some operating systems > mount $HOME as a subvolume, so those won't work either. > > To resolve this, we can use devt to match in the device list and find > the matching fs_devices or NULL. Ugh, this one is ugly. Thanks for noticing that, I think this needs fixing indeed. I've tried here, mounted the same temp-fsid btrfs device in 2 different mount points, and wrote two different files on each. The mount A can only see the file A, mount B can only see file B. Then after unmouting both, I cannot mount anymore with errors in ctree, so it got corrupted. The way I think we could resolve this is by forbidding mounting a temp-fsid twice - after the random uuid generation, we could check for all fs_devices present and if any of it has the same metadata_uuid, we check if it's the same dev_t and bail. The purpose of the feature is for having the same filesystem in different devices able to mount at the same time, but on different mount points. WDYT? Cheers!
