Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-detect subvolume mountpoints within volume paths #237

Open
tasket opened this issue Feb 13, 2025 · 0 comments
Open

Auto-detect subvolume mountpoints within volume paths #237

tasket opened this issue Feb 13, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@tasket
Copy link
Owner

tasket commented Feb 13, 2025

Problem:

Currently Wyng requires references to local Btrfs storage to be a subvolume mountpoint. However, this ignores the possibility that other subvolumes may be nested along the sub-paths of one or more disk image files; any image file within such a 'sub-subvolume' path would not actually reside in the --local subvolume that Wyng is trying to snapshot and Wyng would probably halt with errors during delta acquisition.

Expecting the user to always have their disk image directory free of additional subvols may be too much to ask.

Solution:

Get a complete list of subvolume mounts for the referenced filesystem and see if any match the paths of the disk images. Then possibly have get_reflink_deltas() call itself recursively to handle the imgs in the embedded subvols.

Also, bind-mounts will have to be detected.

Workarounds:

  • Move or reflink the failing disk image to a path within the referenced --local subvol.
  • Exclude the failing/nested disk image from the main backup session, then run another session with --local pointing instead to the nested subvol.
@tasket tasket added the bug Something isn't working label Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant