Re: [PATCH v2] btrfs: Remove received information from snapshot on ro->rw switch

[Graham Cobb <g.btrfs@cobb.uk.net>]

On 09/09/2021 07:46, Nikolay Borisov wrote:
> 
> 
> On 9.09.21 г. 0:24, Graham Cobb wrote:
>>
>> On 08/09/2021 19:33, David Sterba wrote:
>>> On Wed, Sep 08, 2021 at 04:34:47PM +0000, Martin Raiber wrote:
>>
>> <snip>
>>
>>>> For example I had the problem of partial subvols after a sudden
>>>> restart during receive. No problem, just receive to a directory that
>>>> gets deleted on startup then move the subvol to the final location
>>>> after completion. To move the subvol it needs to be temporarily set rw
>>>> for some reason. I'm sure there is some better solution but patterns
>>>> like this might be out there.
>>>
>>> Thanks, that's a case we should take into account. And there are
>>> probably more, but I'm not using send/receive much so that's another
>>> reason why I've been hesitant to merge the patch due to lack of
>>> understanding of the use case.
>>>
>>
>> This seems to be an important change to make, but is user-affecting. A
>> few ideas:
>>
>> 1) Can it be made optional? On by default but possible to turn off
>> (mount option, sys file, ...) if you really need to retain the current
>> behaviour.
> 
> But the current behavior is buggy and non-intentional so it should be
> rectified. Basically we've made it easy for users to do something which
> they shouldn't really be doing, they then bear the consequences and come
> to the mailing list for support thinking something is broken.

Yes, I agree completely. I was disappointed the change wasn't made last
time this was discussed on the list. But it wasn't. And I think that was
because of concern over the impact: the change will break some users'
workflows or scripts and could break some important tools, apps or
things like distro installation/upgrade scripts. That was the purpose of
my suggestions: to break down barriers which might delay making this happen.

>> 2) Is there a way to engage with the developers and user community for
>> popular tools which make heavy use of snapshotting and/or send/receive
>> for discussion and testing? For example, btrbk, snapper, distros.

The point of this suggestion was to address David's concern of not
understanding the use case. This could be useful when discussing the
timing of the fix (and whether it can be backported to stable kernels).

>> 3) How about adding an IOCTL to allow the user to set/delete the
>> received_uuid? Only intended for cases which really need to emulate the
>> removed behaviour. This could be a less complex long term solution than
>> keeping option 1 indefinitely.

And this suggestion was to make it "possible" to work round the change
but, in practice, harder than just doing the right thing :-) I agree
this is probably too far.

Graham