btrfs-receive complains about not being able to open its temporary file(s) (e.g. o123802-148688-0) #147
Description
(I made the post on mailing list as well but it will get/got burdened under emails - so adding issue here as well)
I have small btrfs filesystem (originally used for systemd's containers, mounted over /var/lib/machines as a loopback). The filesystem is fully clean - or at least seems so - no errors of any kind are reported via btrfs-scrub or btrfs-check.
The structure is as follows:
17:35 # btrfs subvolume list /src -qu
ID 263 gen 141492 top level 5 parent_uuid - uuid e3a77929-0e4d-6744-9aed-d4d6a4de5f78 path xenial
ID 340 gen 134847 top level 5 parent_uuid e3a77929-0e4d-6744-9aed-d4d6a4de5f78 uuid f05f0983-3954-e440-ba54-3cc1d458f317 path xenial2
ID 461 gen 160056 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid 3292eba1-4129-b841-9ab9-8a4b03d79187 path orig1
ID 462 gen 160532 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid c806ca4d-40c1-e04a-b33f-7799648f8aff path tr
ID 464 gen 160056 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid 51de47cb-9fbb-a64b-84c9-0ed7614cba22 path edge1
ID 465 gen 160056 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid bcfe5026-d781-b04e-83e1-c20b9b57f1c6 path edge2
ID 466 gen 160542 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid bc3035c5-1609-be4f-959a-2cf89559df08 path anal1
ID 475 gen 160062 top level 5 parent_uuid f05f0983-3954-e440-ba54-3cc1d458f317 uuid 5e23ff06-dbbb-7743-966f-75408084be36 path back1
ID 488 gen 160056 top level 5 parent_uuid 5e23ff06-dbbb-7743-966f-75408084be36 uuid 06a5956f-864d-4243-b303-3e9768a24a31 path back2
The interesting (problematic) part is xenial -> xenial2 -> back1 -> back2
As I recreated my main filesystem as btrfs, I wanted to move the old stuff with btrfs send/receive - and everything worked fine except back2.
mount /dev/loop0 /src -o noatime
for x in /src/*; do btrfs property set "$x" ro; done
btrfs send /src/xenial | btrfs receive -v -e /var/lib/machines/
btrfs send -p /src/xenial /src/xenial2 | btrfs receive -v -e /var/lib/machines/
btrfs send -p /src/xenial2 /src/orig1 | btrfs receive -v -e /var/lib/machines/
# ...
btrfs send -p /src/xenial2 /src/back1 | btrfs receive -v -e /var/lib/machines/
# and the failing one:
btrfs send -p /src/back1 /src/back2 | btrfs receive -v -e /var/lib/machines/
The last of the above commands exits with ERROR: cannot open /var/lib/machines/back2/o123802-148688-0: No such file or directory.
This looks like a bug, though perhaps I'm doing something fundamentally wrong. The sequence is 100% reproducible (I keep the source fs intact - so I can provide any debug output or assist as necessary).
Tested (so far) with:
kernel version: 4.18.3, 4.18.9
btrfs-progs: 4.17.1