Re: Using send/receive to keep two rootfs-partitions in sync fails with "ERROR: snapshot: cannot find parent subvolume"

[Andrei Borzenkov <arvidjaar@gmail.com>]

On 08.01.2024 22:36, Clemens Eisserer wrote:
> Hi Andrei,
> 
>> The error is correct. There is no subvolume with UUID
>> 29fca96e-ca6a-3d4b-b7c9-566f1240d978 and according to the output in your
>> other mail there are no received UUIDs which breaks send/receive chain.
>>
>> Unfortunately the output you sent was *after* your script already
>> destroyed the original state of both filesystems - it recreated
>> subvolumes without running successful send/receive first. So we still do
>> not know the state when error happened.
> 
> I am really sorry, I didn't think of this.
> 
> I've followed your suggestions and tried to reproduce it once again.
> This time I booted from extern/root-rw two times and performed
> ext->int->ext in between, but didn't manually change files like in the
> previous runs.
> After the second boot send/receive failed as expected. I've omitted
> manual mounts/unmounts this time from the command-list.
> 
> 
> I would be really glad if you could - once again - have a look at the results:
> 
> btrfs send source_disk/root-ro | btrfs receive extern/ #initial source->ext
> btrfs send extern/root-ro | btrfs receive intern/ #initial ext -> int
> btrfs sub snap extern/root-ro extern/root-rw # rw snapshot to modify
> ext, will be used as subvol when booting
> btrfs sub snap intern/root-ro intern/root-rw # rw snapshot to modify
> int, won't be used
> 
> # boot fedora from extern (+ install firefox via dnf) + shutdown again
> 
> btrfs subvolume list -pqRu intern/
> ID 386 gen 576 parent 5 top level 5 parent_uuid -
>                received_uuid 8d1ee193-2522-014b-b436-032f0a4fc461 uuid
> a88bb4ed-65c8-db4f-b209-9ca07eaf3d21 path root-ro
> ID 387 gen 576 parent 5 top level 5 parent_uuid
> a88bb4ed-65c8-db4f-b209-9ca07eaf3d21 received_uuid -
>                   uuid f4d1c9cc-3e4b-4248-9b02-626bed3ad238 path
> root-rw
> 
> btrfs subvolume list -pqRu extern/
> ID 345 gen 588 parent 5 top level 5 parent_uuid -
>                received_uuid 8d1ee193-2522-014b-b436-032f0a4fc461 uuid
> 21cabdfd-02f5-ab4b-943a-6ebf88326dae path root-ro
> ID 346 gen 611 parent 5 top level 5 parent_uuid
> 21cabdfd-02f5-ab4b-943a-6ebf88326dae received_uuid -
>                   uuid 0c9d9843-32f3-d341-b657-a33de46c9d0e path
> root-rw
> 
> sh sync_ext_to_int.sh
> 
> btrfs subvolume list -pqRu intern/
> ID 388 gen 583 parent 5 top level 5 parent_uuid
> a88bb4ed-65c8-db4f-b209-9ca07eaf3d21 received_uuid
> b326e1fe-7295-3948-a401-b6de850e213c uuid
> f055e3e8-d048-744c-abb4-c3efd87c4875 path root-ro
> ID 389 gen 583 parent 5 top level 5 parent_uuid
> f055e3e8-d048-744c-abb4-c3efd87c4875 received_uuid -
>                   uuid da51f30f-f10a-b04c-b7a7-5e718118a49c path
> root-rw
> 
> btrfs subvolume list -pqRu extern/
> ID 346 gen 615 parent 5 top level 5 parent_uuid
> 21cabdfd-02f5-ab4b-943a-6ebf88326dae received_uuid -
>                   uuid 0c9d9843-32f3-d341-b657-a33de46c9d0e path
> root-rw
> ID 347 gen 615 parent 5 top level 5 parent_uuid
> 0c9d9843-32f3-d341-b657-a33de46c9d0e received_uuid -
>                   uuid b326e1fe-7295-3948-a401-b6de850e213c path
> root-ro
> 
> sh sync_int_to_ext.sh (intern was not changed, just to keep ext->int,
> int->ext in order)
> 

This should have failed already and the real question is why it did not. 
The parent subvolume is identified by rceieved_uuid which is missing.

> btrfs subvolume list -pqRu intern/
> ID 389 gen 588 parent 5 top level 5 parent_uuid
> f055e3e8-d048-744c-abb4-c3efd87c4875 received_uuid -
>                   uuid da51f30f-f10a-b04c-b7a7-5e718118a49c path
> root-rw
> ID 390 gen 588 parent 5 top level 5 parent_uuid
> da51f30f-f10a-b04c-b7a7-5e718118a49c received_uuid -
>                   uuid 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 path
> root-ro
> 
> btrfs subvolume list -pqRu extern/
> ID 348 gen 623 parent 5 top level 5 parent_uuid
> b326e1fe-7295-3948-a401-b6de850e213c received_uuid
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f path root-ro
> ID 349 gen 623 parent 5 top level 5 parent_uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f received_uuid -
>                   uuid cf80f17f-3d5d-7744-83f4-096b7688288c path
> root-rw
> 
> # boot fedora from extern (remove google-chrome and chromium via dnf)
> + shutdown again
> 
> btrfs subvolume list -pqRu extern/
> ID 348 gen 623 parent 5 top level 5 parent_uuid
> b326e1fe-7295-3948-a401-b6de850e213c received_uuid
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f path root-ro
> ID 349 gen 633 parent 5 top level 5 parent_uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f received_uuid -
>                   uuid cf80f17f-3d5d-7744-83f4-096b7688288c path
> root-rw
> 
> sh sync_ext_to_int.sh
> 
> manually executed line-by-line in expecting it would fail it failed at:
> btrfs send -p extern/root-ro extern/root-ro-new | btrfs receive intern/
> At subvol extern/root-ro-new
> At snapshot root-ro-new
> ERROR: clone: cannot find source subvol 8a1f263b-581d-1847-a0da-0fc17e1ca2c4
> 
> interestingly, despite send-receive failed/aborted with the message
> above, intern/root-ro-new was created and contains contents but left
> in writable state:
> 

Correct. Where "btrfs receive" fails is cloning extents from the parent 
subvolume. The difference is that rebooting performs much larger 
modifications of the root-rw subvolume which triggers "clone" operation 
during send/receive. Your test runs basically do nothing. Post output of

btrfs send -p extern/root-ro extern/root-ro-new | btrfs receive --dump

I do not know off-hand how to trigger "clone" operation.

It is definitely "btrfs receive" bug. Either it should fail from the 
very beginning due to missing received_uuid or it should consistently 
fall back to subvolume uuid in all cases. But starting with subvolume 
that cannot be later used to apply incremental changes is certainly the 
wrong thing to do.

> btrfs sub show intern/root-ro-new/
> root-ro-new
>          Name:                   root-ro-new
>          UUID:                   d32788b9-5572-5743-bf27-46b57c8b92c1
>          Parent UUID:            8a1f263b-581d-1847-a0da-0fc17e1ca2c4
>          Received UUID:          -
>          Creation time:          2024-01-08 20:14:59 +0100
>          Subvolume ID:           391
>          Generation:             596
>          Gen at creation:        594
>          Parent ID:              5
>          Top level ID:           5
>          Flags:                  -
>          Send transid:           0
>          Send time:              2024-01-08 20:14:59 +0100
>          Receive transid:        0
>          Receive time:           -
>          Snapshot(s):
>          Quota group:            n/a
> 
> 
> btrfs subvolume list -pqRu intern/
> ID 389 gen 588 parent 5 top level 5 parent_uuid
> f055e3e8-d048-744c-abb4-c3efd87c4875 received_uuid -
>                   uuid da51f30f-f10a-b04c-b7a7-5e718118a49c path
> root-rw
> ID 390 gen 594 parent 5 top level 5 parent_uuid
> da51f30f-f10a-b04c-b7a7-5e718118a49c received_uuid -
>                   uuid 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 path
> root-ro
> ID 391 gen 595 parent 5 top level 5 parent_uuid
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 received_uuid -
>                   uuid d32788b9-5572-5743-bf27-46b57c8b92c1 path
> root-ro-new
> 
> 
> btrfs subvolume list -pqRu extern/
> ID 348 gen 623 parent 5 top level 5 parent_uuid
> b326e1fe-7295-3948-a401-b6de850e213c received_uuid
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f path root-ro
> ID 349 gen 636 parent 5 top level 5 parent_uuid
> c481acb9-b077-7841-a4b6-a0273f7aa12f received_uuid -
>                   uuid cf80f17f-3d5d-7744-83f4-096b7688288c path
> root-rw
> ID 350 gen 636 parent 5 top level 5 parent_uuid
> cf80f17f-3d5d-7744-83f4-096b7688288c received_uuid -
>                   uuid d73b4afe-0837-8046-b798-21102cb82d4d path
> root-ro-new
> 
> Looking at the last output I have to admit I am confused.
> The error mentioned missing parent with
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4 for intern/root-ro-new seems to
> be there. Isn't this, as expected intern/root-ro with
> 8a1f263b-581d-1847-a0da-0fc17e1ca2c4.
> 
> Thanks for all your patience and help!
> 
> Best regards, Clemens