On Wed, Sep 20, 2023 at 09:16:02AM -0300, Guilherme G. Piccoli wrote: > 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... Yeah, fstests are not in general ready for enabling some feature from the outside (mkfs, or mount options). Some of them work as long as they're orthogonal but some tests need to detect that and skip. In this case all multidevice tests would fail. For test coverage there should be at lest one test that verifies known set of compatible features or usecases we care about in comibnation with the temp-fsid. > > 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? The subvolume mount is a common use case and I hope it continues to work. Currently it does not seem so as said above, for correctness we may need to prevent it. We might find more and this should be known or fixed before final release.
