thanks for the comments, more inline below.
- btrfstume -M <uuid> isn't the place to check if the fsid is a duplicate. Because, libblkid will be unaware of the complete list of fs images with its fsid.I don't understand this part. Blkid tracks the device iformation, like the uuid, and the cache gets updated. So what does 'will be unaware of the complete list' mean? If it's on the same host it's a matter of keeping the cache in sync with the actual devices.
In case of vm guest images copied from the golden image there is no physical device or loop device or nbd device until its configured on the host when required, so check for duplicate fsid at the time of btrfstune -M is not convincing or a very limited approach.
- As I said before, its a genuine use-case here where the user wants to revert the fsid change, so that btrfs fs root image can be booted. Its up-to the user if fsid is duplicate in the user space, as btrfs kernel rightly fails the mount if its duplicate fsid anyways.Reverting the uuid is fine
ok thanks.
and requiring the uuids to be unique is preventing the users doing stupid things unknowingly.
Right it should be done. But.. btrfstune -M is a wrong place. Because it can't avoid all the cases of fsid getting duplicated. Even after btrfstune -M, the fsid can be duplicated by the user. So what's the point in restricting the btrfstune -M and fail to undo the changed fsid.
You seem to have a usecase where even duplicate uuids are required but I'm afraid it's not all clear how is it supposed to work. A few more examples or commands would be helpful.
In the use case here, even the host is also running a copy of the golden image (same fsid as vm guest) and because of duplicate fsid you can only mount a vm guest image on the host after the btrfstune -m command on the vm guest image. But after you have done that, as the vm guest fsid is changed, it fails to boot, unfortunately changed fsid can not be undone without this patch. The fsid can be duplicate by many different other ways anyways. So in this case how does it matter if btrfstune -M tries to ensure that fsid is unique among the blkid known set of devices, which may change any time after btrfstune -M as well (just copy a vm guest and map it to a loop device). So btrfstune -M should be free from this check and help the use case as above. And if we are concerned about the duplicate fsid as I asked Nikolay before, we need to know what are problems in specifies, so that it can be fixed in separate patches, but definitely not in btrfstune -M as it can't fix the duplicate fsid problem completely as vm images can be copied and mapped to a loop/nbd device anytime even after btrfstune -M. Thanks, Anand
