Re: btrfs send and receive showing errors

[Andrei Borzenkov <arvidjaar@gmail.com>]

On 05.01.2023 20:48, Andrei Borzenkov wrote:
> On 05.01.2023 19:47, Randy Nürnberger wrote:
>> On Thu, Jan 5, 2023 at 17:35, Randy Nürnberger wrote:
>>> On Thu, Jan 5, 2023 at 17:01, Andrei Borzenkov wrote:
>>>> On 05.01.2023 18:55, Randy Nürnberger wrote:
>>>>>
>>>>> I’ve attached the output of ‘btrfs subvolume list’ for the source and
>>>>> the target filesystem.
>>>>>
>>>>
>>>> You have a lot of source subvolumes with the same received_uuid and
>>>> you have at least two destination subvolumes with the same
>>>> received_uuid. This is wrong, received_uuid is supposed to be unique
>>>> identification which explains your errors (incorrect subvolume is
>>>> selected).
>>>
>>> I guess many of my source subvolumes have the same received_uuid,
>>> because I created new snapshots from a snapshot that was previously
>>> received and the received_uuid just did get copied.
>>>
>>> I just did a small experiment on another system, created a snapshot
>>> from a snapshot that previously was received and could confirm that
>>> the received_uuid does indeed get copied. Is this a problem?
>>
> 
> No, it is not a problem by itself. Subvolumes used for send/receive are
> supposed to be a remain read-only, so any clone of any subvolume should
> have identical content and you can use any of the clones with the same
> received_uuid. But as soon as you made subvolume read-write, you got
> multiple subvolumes with different content and the same receive_uuid.
> "Doctor, it hurts when I stab myself in the eye".
> 
> Never, NEVER, ever, change  subvolume involved in send/receive to
> read-write to use it; clone it (create writable snapshot) and use clone.
> 
>> Ha! This seems to be the problem! I’m able to write a small script that
>> reproduces the bug! Give me a couple minutes.
>>
>> If this is a bug in the kernel,
> 
> It is not so much a bug as the consequence of unfortunate design.
> 
>> may I write the patch? :D Would be my
>> first one :)
> 
> The problem is known for years (just search this list) and there are
> patches to clear received_uuid on ro -> rw transition but they are still
> not applied. Personally I would just prohibit such transition completely.

Correction - it was decided to implement in btrfs utils, not in kernel, 
so "btrfs property" will by default refuse to make read-write subvolume 
with received_uuid. This is implemented in 5.14.2.