summaryrefslogtreecommitdiffstats
path: root/fs/btrfs/disk-io.c
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fb.com>2015-06-04 17:17:25 -0400
committerChris Mason <clm@fb.com>2015-06-12 13:20:38 -0700
commit37b8d27de5d0079e1ecef2711061048e13054ebe (patch)
treeca36f955398f3e3dc9f369bee28bbcc125d8b628 /fs/btrfs/disk-io.c
parent0eeff2362b829b5e80f8b69f86b60b8094bc742d (diff)
downloadlinux-37b8d27de5d0079e1ecef2711061048e13054ebe.tar.bz2
Btrfs: use received_uuid of parent during send
Neil Horman pointed out a problem where if he did something like this receive A snap A B change B send -p A B and then on another box do recieve A receive B the receive B would fail because we use the UUID of A for the clone sources for B. This makes sense most of the time because normally you are sending from the original sources, not a received source. However when you use a recieved subvol its UUID is going to be something completely different, so if you then try to receive the diff on a different volume it won't find the UUID because the new A will be something else. The only constant is the received uuid. So instead check to see if we have received_uuid set on the root, and if so use that as the clone source, as btrfs receive looks for matches either in received_uuid or uuid. Thanks, Reported-by: Neil Horman <nhorman@redhat.com> Signed-off-by: Josef Bacik <jbacik@fb.com> Reviewed-by: Hugo Mills <hugo@carfax.org.uk> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/btrfs/disk-io.c')
0 files changed, 0 insertions, 0 deletions