On Fri, May 05, 2023 at 01:18:56PM -0300, Guilherme G. Piccoli wrote: > On 05/05/2023 10:18, David Sterba wrote: > > [...] > > 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. > > 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.
