btrfs send -c fails saying "parent determination failed"

Hi,

btrfs send -c stopped working for me several months ago. My setup is actually very simple. On the "send" side I have:

# btrfs sub list -u / | grep rootfs-snapshot-
ID 2221 gen 93340 top level 5 uuid adf43113-0442-9847-9ce4-7d9c06e77602
path rootfs-snapshot-20150923
ID 2262 gen 96026 top level 5 uuid 49f34ca5-42da-7d4b-a159-c3027650d8e6
path rootfs-snapshot-20150929

Several other subvolumes also exist there, just in case it matters. On the receive side:

# btrfs sub list -R /mnt/cryptobackup/ | grep rootfs-snapshot-20150923
ID 1532 gen 3066 top level 5 received_uuid
adf43113-0442-9847-9ce4-7d9c06e77602 path snapshots/rootfs-snapshot-20150923

As you can see the uuids for rootfs-snapshot-20150923 are the same on both sides. If I try to send|receive /rootfs-snapshot-20150929 using rootfs-snapshot-20150923 as clone source it fails:

# btrfs send -c /rootfs-snapshot-20150923 /rootfs-snapshot-20150929 |
btrfs receive /mnt/cryptobackup/snapshots/
At subvol /rootfs-snapshot-20150929
ERROR: parent determination failed for 2221

while it works fine if I use btrfs send -p. This is always reproducible, it fails every time across reboots and kernel upgrades; it works every time with -p.

In both / and /mnt/cryptobackup I didn't mount any special subvolid:

# btrfs sub get-default /
ID 5 (FS_TREE)
# btrfs inspect-internal rootid /
5
# btrfs sub get-default /mnt/cryptobackup/
ID 5 (FS_TREE)
# btrfs inspect-internal rootid /mnt/cryptobackup/
5

so nothing strange here. Some other possibly useful information:

$ uname -a
Linux mandragola 4.2.0-1-amd64 #1 SMP Debian 4.2.1-1 (2015-09-25) x86_64
GNU/Linux

so you have guessed that I'm running an up to date Debian system. Keep in mind that it is several kernel versions that I'm getting this problem, it's nothing specific to this one.

$ btrfs --version
btrfs-progs v4.1.2

# btrfs fi show
Label: none  uuid: 5651d651-5c48-425f-9fc9-56f2a9ad004f
	Total devices 1 FS bytes used 118.24GiB
	devid    1 size 237.97GiB used 218.02GiB path /dev/sda2

Label: none uuid: c4db7f4f-b976-4d36-bd76-76e818341cef
Total devices 1 FS bytes used 934.71GiB
devid 1 size 1.82TiB used 941.03GiB path /dev/mapper/cryptobackup

$ btrfs fi df /
Data, single: total=212.01GiB, used=116.98GiB
System, single: total=4.00MiB, used=48.00KiB
Metadata, single: total=6.01GiB, used=1.27GiB
GlobalReserve, single: total=448.00MiB, used=0.00B

$ btrfs fi df /mnt/cryptobackup/
Data, single: total=932.00GiB, used=931.70GiB
System, DUP: total=8.00MiB, used=128.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=4.50GiB, used=3.01GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=512.00MiB, used=0.00B

$ dmesg | grep -i btrfs | curl -F "sprunge=<-" http://sprunge.us
http://sprunge.us/EiHE

If I hit a bug I'll be happy to help in finding it, just tell me if you need further information. Otherwise, if I'm just missing something, I'll appreciate any hint.

Thank you,

Paride

[...]

Hi again, my previous email didn't get any reply, maybe it was too long. I try to summarize:

btrfs send -c | btrfs receive

always fails for me with "parent determination failed" even if the UUIDs are correct, and indeed btrfs send -p works fine on the same subvols.

My setup is quite standard (more details in the original email), so I'm prone to think that the problem is with btrfs-progs.

I'll be happy to provide any information that could help to find where the problem lies. If there is no interest in this I'll live with -p, but with the uncomfortable feeling that a bug may be hiding somewhere...

Paride

Hi,

I have the same problem here. I'd love to stop using rsync in place of send recieve. As with Paride my _working_ scripts just stop functioning...

Thanks
Ed