Re: [PATCH v4] btrfs: Remove received_uuid during received snapshot ro->rw switch

[Hans van Kranenburg <hans.van.kranenburg@mendix.com>]

On 10/06/2017 07:24 PM, David Sterba wrote:
> On Thu, Oct 05, 2017 at 05:03:47PM +0800, Anand Jain wrote:
>> On 10/05/2017 04:22 PM, Nikolay Borisov wrote:
>>> Currently when a read-only snapshot is received and subsequently its ro property
>>> is set to false i.e. switched to rw-mode the received_uuid of that subvol remains
>>> intact. However, once the received volume is switched to RW mode we cannot
>>> guaranteee that it contains the same data, so it makes sense to remove the
>>> received uuid. The presence of the received_uuid can also cause problems when
>>> the volume is being send.

Are the 'can cause problems when being send' explained somewhere?

>>
>> Wonder if this [1] approach was considered
>> [1]
>>   - set a flag on the subvolume to indicate its dirtied so that 
>> received_uuid can be kept forever just in case if user needs it for some 
>> reference at a later point of time.
> 
> Yeah, we need to be careful here. There are more items related to the
> recived subvolume, besides received_uuid there's rtransid and rtime so
> they might need to be cleared as well.
> 
> I don't remember all the details how the send/receive and uuids
> interact. Switching from ro->rw needs to affect the 'received' status,
> but I don't know how. The problem is that some information is being lost
> although it may be quite important to the user/administrator. In such
> cases it would be convenient to request a confirmation via a --force
> flag or something like that.

On IRC I think we generally recommends users to never do this, and as a
best practice always clone the snapshot to a rw subvolume in a different
location if someone wants to proceed working with the contents and
changing them as opposed to messing with the ro/rw attributes.

So, what about option [2]:

[2] if a subvolume has a received_uuid, then just do not allow changing
it to rw.

Even if it wouldn't make sense for some reason, it's a nice thought
experiment. :)

-- 
Hans van Kranenburg