btrfs receive occasionally fails to find parent subvolume when data flows in the reverse direction #606
Comments
|
OK, I've scratched a test with all these snapshots mangling. And it worked flawlessly (see log.txt). 🙄 Here's what it retains in the end: I suspect it's just one of the snapshots I have is somehow bugged, and I just need to start a new lineage. Tell me if you want to me to push the test. Feel free to incorporate it yourself. |
|
After working flawlessly for two weeks, I've got to the same state again. This is the state after The new snapshot, I think I had an asynchronized kernel update 6.2.7 → 6.2.11 recently, like on 2023-04-15 on PC1 and 2023-04-17 on PC2. Since then I had correct "to PC1" - "to PC2" cycle around 2023-04-19. I'll keep the snapshots around, so that it is possible to debug them. Please tell me, what diagnostics I can perform. P.S. I wonder if clearing older snapshots in PC1 and PC2 might somehow influence this. |
ettavolt
changed the title
|
I also ran into the same issue when syncing snapshot back and forth between two different systems using What I don't understand though, is why I only ran into this issue recently. I have been keeping my two systems in sync by sending snapshots back and forth for around 5 years and it used to mostly work (though I still had to do full transfers a handful of times, which may have been due to this issue). |
|
This happens only if one of the files is partially updated involving CoW mechanism. I don't think there is a lot of software doing that. |
|
Thanks, that makes sense as an explanation of why this issue can become more (or less) frequent with time and not just happen all the time. In my case, I went back to the unpatched btrfs-progs and managed to reproduce the issue again, and the culprit (= |
…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 <[email protected]> Signed-off-by: David Sterba <[email protected]>
|
Now fixed in devel, by PR #643. I'm not sure it's entirely correct to switch the uuids for matching subvolume, there are some obscure states and combinations and I don't remember if there wasn't a specific reason to do it like it is. But you have a real world use case so it counts. |
|
Somehow if I navigate to the updated commit, 1ebdb7d, GitHub says
I've looked through the history of devel branch and don't see it there. |
|
@kdave, sorry, but the PR wasn't merged, and v6.9 doesn't include the fix. |
|
Moved to 6.9.2 target. |
|
I've rebased the branch on top of |
|
I can't reopen the pull request (the button is disabled in the UI), please open a new one. |
|
Done. |
…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 <[email protected]> Signed-off-by: David Sterba <[email protected]>
…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 <[email protected]> Signed-off-by: David Sterba <[email protected]>
…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 <[email protected]> Signed-off-by: David Sterba <[email protected]>
I'm trying to carry user profile between two laptops via backups on an external disk (so that I have sync and backups and the same time).
For that I'm trying to utilize the following structure:
profile, btrfs subvolume:
/home/ask-rbrbtrfs ro snapshots:
/home/.ask-rbr-snapshots/@yyyy-MM-dd[Thh[:mm[:ss]]]external drive, btrfs ro snapshots:
/run/rbrssd/ask-arch-profile/@yyyy-MM-dd[Thh[:mm[:ss]]]Both systems are running Arch with:
linux 6.2.7.arch1-1
btrfs-progs 6.2.1-1
(one might be lagging by a week).
This is an extension of earlier backup-only setup, when
send | receivewas going profile → external drive direction only.The problem happens when I try to send recent backup to laptop to recreate profile (making it a rw snapshot of most recent ro snapshot).
External drive:
Hexdump of first 128 bytes of
btrfs send -p ask-arch-profile/@2023-03-16T11 ask-arch-profile/@2023-03-21:Laptop backups:
And output of
btrfs receive /home/.ask-rbr-snapshots:and 1 as the exit code.
However, snapshot has been correctly transferred:
I think this is unrelated to #538, because transfer works seemlessly into the other direction.
Might this happen because I had a break in day-to-day snapshots before 03-18? (See that snapshot having no parent uuid)?
The text was updated successfully, but these errors were encountered: