Re: btrfs send and receive showing errors

["Randy Nürnberger" <ranuberger@posteo.de>]

On Thu, Jan 5, 2023 at 19:04, Andrei Borzenkov wrote:
> 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.

I mistakenly thought that creating a new writable snapshot and making a 
read-only snapshot writable were the same operation.

Thinking about it, I understand the difference and why it is there.

>>
>>> 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.

With this knowledge I managed to repare and successfully copy my filesystem.

I have learned a lot. Thank you both for helping me and for your time.