btrfs-progs: receive: cannot find clone source subvol when receiving in reverse direction #643
Conversation
|
New test before the change: test-fail.log Note, I've collected these with |
|
Why did it decide to fail in |
|
The test 028 randomly fails in the github CI, I don't know why, you don't have to worry about it. |
|
The first parameter of (Note that there are two different declarations of (Also posted to LKML before I saw that there was also an open PR, sorry for the spam) |
|
Thanks, joanbm. To me that looked like a copy-paste error. ☺ |
|
Sorry, kdave, do I need to do something else to have this merged? |
|
Hi @kdave, sorry for the noise, but can this be merged please? Is there anything I can do to improve the patch? |
when receiving in reverse direction process_clone only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com>
|
Sorry, I keep forgetting about this PR. Marked for 6.8.1 or 6.9 at the latest. |
…in reverse direction process_clone() only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Issue: #606 Pull-request: #643 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
|
Now added to devel, thanks. As said in #606 I don't remember if there was a reason to do it as before, some use cases were not meant to be possible and some of them were with reverse receive. I hope nothing else breaks (we had such cases unfortunatelly). |
|
Minor changes to the test case: indentation and parameter quoting. |
…in reverse direction process_clone() only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Issue: #606 Pull-request: #643 Pull-request: #862 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
…in reverse direction process_clone() only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Issue: #606 Pull-request: #643 Pull-request: #862 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
…in reverse direction process_clone() only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Issue: #606 Pull-request: #643 Pull-request: #862 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
…in reverse direction process_clone() only searches the received_uuid, but could exist in an earlier uuid that isn't the received_uuid. Mirror what process_snapshot does and search both the received_uuid and if that fails look up by normal uuid. Fixes: #606 Issue: #606 Pull-request: #643 Pull-request: #862 Signed-off-by: Arsenii Skvortsov <ettavolt@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
process_clone, unlike process_snapshot, only searched a subvolume matching by received uuid. However, when earlier "receiver" side sends, it mentions received uuid, which is for earlier "send" side (now "receiver" side) is just uuid.
Fixes #606.