btrfs-progs
btrfs-progs copied to clipboard
kdave
btrfs-progs: receive: cannot find clone source subvol when receiving in reverse direction
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.
New test before the change: test-fail.log and after: test-pass.log.
Note, I've collected these with btrfs -v receive, which is not set in what I've pushed.
Looks like ubuntu-latest is 22.04, not even 23.04, or dd would have known oseek.
I've changed the test to old parameter name.
Why did it decide to fail in 028-superblock-recover now, but not during previous run? :-O
The test 028 randomly fails in the github CI, I don't know why, you don't have to worry about it.
Looks like ubuntu-latest is 22.04, not even 23.04, or
ddwould have knownoseek.
Yeah the CI images are old (kernel and user space), so the tests have to test for new features or not use new functionality.
The first parameter of search_source_subvol should be changed from a struct subvol_uuid_search * to an int, which I suggest naming mnt_fd, otherwise this generates some integer <->pointer conversion warnings.
(Note that there are two different declarations of subvol_uuid_search in btrfs-progs, which probably caused the confusion with the typings).
(Also posted to LKML before I saw that there was also an open PR, sorry for the spam)
Hi @kdave, sorry for the noise, but can this be merged please? Is there anything I can do to improve the patch?
Sorry, I keep forgetting about this PR. Marked for 6.8.1 or 6.9 at the latest.
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).