On 05/05/2023 20:00, David Sterba wrote: > [...] >> Hi David, thanks for your suggestion! >> >> It might be possible, it seems a valid suggestion. But worth notice that >> we cannot modify the FS at all. That's why I've implemented the feature >> in a way it "fakes" the fsid for the driver, as a mount option, but >> nothing changes in the FS. >> >> The images on Deck are read-only. So, by using the metadata_uuid purely, >> can we mount 2 identical images at the same time *not modifying* the >> filesystem in any way? If it's possible, then we have only to implement >> the skip scanning idea from Qu in the other thread (or else ioclt scans >> would prevent mounting them). > > Ok, I see, the device is read-only. The metadata_uuid is now set on an > unmounted filesystem and we don't have any semantics for a mount option. > > If there's an equivalent mount option (let's say metadata_uuid for > compatibility) with the same semantics as if set offline, on the first > commit the metadata_uuid would be written. > > The question is if this would be sane for read-only devices. You've > implemented the uuid on the metadata_uuid base but named it differently, > but this effectively means that metadata_uuid could work on read-only > devices too, but with some necessary updates to the device scanning. > > From the use case perspective this should work, the virtual uuid would > basically be the metadata_uuid set and on a read-only device. The > problems start in the state transitions in the device tracking, we had > some bugs there and the code is hard to grasp. For that I'd very much > vote for using the metadata_uuid but we can provide an interface on top > of that to make it work. OK, being completely honest here, I couldn't parse fully what you're proposing - I blame it to my lack of knowledge on btrfs, so apologies heh Could you clarify it a bit more? Are you suggesting we somewhat rework "metadata_uuid", to kinda overload its meaning to be able to accomplish this same-fsid mounting using "metadata_uuid" purely? I see that we seem to have 3 proposals here: (a) The compat_ro flag from Qu; (b) Your idea (that requires some clarification for my fully understanding - thanks in advance!); (c) Renaming the mount option "virtual_fsid" to "nouuid" to keep filesystem consistency, like XFS (courtesy of Dave Chinner) - please correct me here if I misunderstood you Dave =) I'd like to thank you all for the suggestions, and I'm willing to follow the preferred one - as long we have a consensus / blessing from the maintainers, I'm happy to rework this as the best possible approach for btrfs. Also, what about patch 2, does it make sense or should we kinda "embed" the idea of scan skipping into the same-fsid mounting? Per my current understanding, the idea (a) from Qu includes/fixes the scan thing and makes patch 2 unnecessary. Thanks, Guilherme
