Re: [PATCH 2/2] btrfs-progs: doc: add extra note on flipping read-only on received subvolumes

[Nikolay Borisov <nborisov@suse.com>]

On 10.09.21 г. 12:59, Qu Wenruo wrote:
> 
> 
> On 2021/9/10 下午5:45, David Sterba wrote:
>> On Fri, Sep 10, 2021 at 09:33:41AM +0300, Nikolay Borisov wrote:
>>>
>>>
>>> On 10.09.21 г. 9:03, Qu Wenruo wrote:
>>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>>> ---
>>>>   Documentation/btrfs-property.asciidoc | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/btrfs-property.asciidoc
>>>> b/Documentation/btrfs-property.asciidoc
>>>> index 4796083378e4..8949ea22edae 100644
>>>> --- a/Documentation/btrfs-property.asciidoc
>>>> +++ b/Documentation/btrfs-property.asciidoc
>>>> @@ -42,6 +42,12 @@ the following:
>>>>
>>>>   ro::::
>>>>   read-only flag of subvolume: true or false
>>>> ++
>>>> +NOTE: For recevied subvolumes, flipping from read-only to
>>>> read-write will
>>>> +either remove the recevied UUID and prevent future incremental receive
>>>> +(on newer kernels), or cause future data corruption and recevie
>>>> failure
>>>> +(on older kernels).
>>>
>>> Hang on a minute, flipping RO->RW won't cause corruption by itself. So
>>> flipping will just break incremental sends which is completely fine.
>>
>> I'm still not decided if it's 'completely fine' to break incremental
>> send so easily.
>>
> 
> Then even we just keep the existing behavior, we still need some
> educational warning here.
> 
> In that keep-recevied-uuid case, here we just need to warn the users
> about that, later incremental receive may fail and the recevied data may
> not be correct, and call it a day (without any kernel modification).
> 
> In that case, it's all users' fault and except the corrupted data and
> receive failure, everything else should be fine.
> 
> Kernel won't crash, users get their "expected" corrupted data, and we
> won't need to bother the kernel behavior change.
> 
> But I don't think that would be any better than a sudden behavior change...

I wholeheartedly disagree. If we do a behavior change then users must
just adjust which really means they have to make 1 full send. If we keep
the current behavior we are bound to be getting reports of corrupted
data/failed receive of subvolumes. And in the end this would end up
being a huge time sink for the person who ends up investigating this...

> 
> Thanks,
> Qu
>