linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* btrfs send -c fails saying "parent determination failed"
@ 2015-09-29 22:20 Paride Legovini
  2015-10-03 12:41 ` Paride Legovini
  2015-10-03 13:18 ` Ed Tomlinson
  0 siblings, 2 replies; 4+ messages in thread
From: Paride Legovini @ 2015-09-29 22:20 UTC (permalink / raw)
  To: linux-btrfs

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: btrfs send -c fails saying "parent determination failed"
  2015-09-29 22:20 btrfs send -c fails saying "parent determination failed" Paride Legovini
@ 2015-10-03 12:41 ` Paride Legovini
  2015-10-03 13:18 ` Ed Tomlinson
  1 sibling, 0 replies; 4+ messages in thread
From: Paride Legovini @ 2015-10-03 12:41 UTC (permalink / raw)
  To: linux-btrfs

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: btrfs send -c fails saying "parent determination failed"
  2015-09-29 22:20 btrfs send -c fails saying "parent determination failed" Paride Legovini
  2015-10-03 12:41 ` Paride Legovini
@ 2015-10-03 13:18 ` Ed Tomlinson
  1 sibling, 0 replies; 4+ messages in thread
From: Ed Tomlinson @ 2015-10-03 13:18 UTC (permalink / raw)
  To: Paride Legovini; +Cc: linux-btrfs

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

on Tuesday, September 29, 2015 6:20:11 PM EDT, Paride Legovini wrote:
> 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
>
>
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* btrfs send -c fails saying "parent determination failed"
@ 2015-10-14 20:15 Paride Legovini
  0 siblings, 0 replies; 4+ messages in thread
From: Paride Legovini @ 2015-10-14 20:15 UTC (permalink / raw)
  To: linux-btrfs

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-10-14 20:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-29 22:20 btrfs send -c fails saying "parent determination failed" Paride Legovini
2015-10-03 12:41 ` Paride Legovini
2015-10-03 13:18 ` Ed Tomlinson
  -- strict thread matches above, loose matches on Subject: below --
2015-10-14 20:15 Paride Legovini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).