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

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

David, ping on this patch.



On 9/12/19 8:45 AM, Anand Jain wrote:
> 
> 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