On Tue, Sep 10, 2019 at 01:12:43PM +0800, Anand Jain wrote: > > Nikolay, > > >>> This is intended. Otherwise it's an open avenue for the user to shoot > >>> themselves in the foot. > >> > >> I don't understand how? > > Again. Any idea how? Is there any test case? > > <snip> > > > UUID, by definition, are Unique. What you want to is > > to toss the Unique part, meaning we'll really be left with some sort of > > ID. What's more - the UUID is used by libblkid to populate the available > > devices so not making it unique can cause subtle bugs. > > - Irrespective of the fstype, when fs image file is copied/snapshot-ed > the fsid is indeed going to be duplicate. > > - xfs and btrfs kernel doesn't allow duplicate fsid to be mounted which > is fair and accepted. (I remember fixing the duplicate fsid bugs in > the kernel, just fyi if you are concerned about them). > > - ext4 kernel does allow duplicate fsid to be mounted. > > - 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. > - 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 and requiring the uuids to be unique is preventing the users doing stupid things unknowingly. 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.
