Re: [PATCH] btrfs-progs: drop unique uuid test for btrfstune -M

[Anand Jain <anand.jain@oracle.com>]

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