Btrfs snapshotter without snapper #2220
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I consider this PR ready to be reviewed despite being in draft. Probably minor changes could be applied on top of the current logic to make public subvolumeBackend interface and its implementations in order to include specific unit tests. |
anmazzotti
approved these changes
Oct 31, 2024
Yes I agree, so far this is the simplest idea that came to my mind to not duplicate code. Opened to other ideas too 😉 |
Signed-off-by: David Cassany <[email protected]>
This commit adds a backend interface in btrfs snapshotter. The interface essentially wraps snapper and btrfs utilities. The idea is make a pure btrfs implementation of the interface and also a snapper based implementation. The functions that snapper can't provide are simply managed by the btrfs implementation. Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
This commit implements the btrfs backend for the btrfs snapshotter and moves all the logic of specific btrfs client calls there. The backend interface is also refined for that purpose. Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
Signed-off-by: David Cassany <[email protected]>
davidcassany
force-pushed
the
btrfs_snapshotter_without_snapper
branch
from
bc86410
to
a31e34a
Compare
Signed-off-by: David Cassany <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull requests provides a new
subvolumebackendinterface to handle btrfs subvolumes and snapshots. The motivation is to not make snapper strict requirement of the btrfs snapshotter to better suite distributions where snapper is not that much adopted.In any case (even if snapper is not in use) the snapshotter is based and built around common snapper conventions, this is easier from a maintenance perspective and allows to eventually consider switching to snapper at a later point in time.
This PR adds a new config parameter
snapperfor the btrfs snapshotter:If snapper set to
true(this is the default value) the snapshotter will attempt to use snapper, otherwise it will relay entirely onbtrfsutility calls.Snapper can't perform alone all the uses cases that the Elemental Snapshotter interface requires (specially corner cases related to first snapshot), for those cases the
snapperBackendimplementation makes use of thebtrfsBackedimplementation, hopefully this can be improved in up comming snapper releases (openSUSE/snapper#944).This PR includes a couple minor behavior changes (on the snapperBackend) that are actually reflected in unit tests: