btrfs send -c fails saying "parent determination failed"
[Repost with new SPF rules, should not be classified as spam now.] 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.3-1 (2015-10-06) 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 devid1 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 devid1 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs send -c fails saying "parent determination failed"
On 2015-09-30 00:20, Paride Legovini wrote: > Hi, > > btrfs send -c stopped working for me several months ago. [...] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 devid1 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 devid1 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 signature.asc Description: OpenPGP digital signature
[no subject]
subscribe linux-btrfs -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe linux-btrfs -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
