Fix message for sending snapshots from ...
about explicitly disabled datasets, and further in-vivo research
#623
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.
I am debugging my setup with partially-disabled trees of datasets (home dir with setup of a build agent should be backed up, but scratch working areas and caches should not).
Currently
znapzend
lists all datasets as "sending snapshots from..." which is a bit misleading.With this PR I externalize
listDisabledSourceDescendants()
so it applies not only tocreateSnapshot()
but also to e.g.sendRecvCleanup()
. In fact, after some back and forth, the array of known-disabled local (source) descendant dataset names is queried from ZFS once and attached to$backupSet
as@{$backupSet->{srcDisabledDescendants}}
so it can be re-used quickly and in different places.So now the report goes like:
Barring any bugs, this PR should not change the
znapzend
end-user behavior beyond such cosmetics.Looking at some further work ahead, I see a couple of issues with the existing logic (screenshot below):
Currently each dataset not slated for retention must have an explicit
org.znapzend:enabled=off
- and this is not inherited by its descendants (well, it is a "storage=inherited" attribute, but not a "storage=local" so ignored byznapzend
). This is by design so far, but is cumbersome for large setups where I'd want a whole tree pruned with whatever datasets appear there over time, so I propose to add handling for such datasets that can optionally declare bothenabled='on|off'
andrecursion=on
for such purpose (currently there is special handling for datasets that declare only one property and that isenabled
).enabled=off
with recursion in place #625Logic for these disablements is such that a recursive snapshot of the backupSet (the one with a full znapzendzetup schedule) is made atomically, data is sent, and then disabled snapshots get removed locally and remotely.
oracleMode
even if it is not asked for in config (and then exclusions quickly skipped from sending)? @oetiker : WDYT? :) UPDATE: A proposal about this quick skip is tackled in Handle not-sending of not-enabled datasets #626rpool/home/abuild/.ccache
is sent below,rpool/home/abuild/jenkins-nut-altroots
is not, both are disabled. In fact it seems that the sending (with attempt to unmount and redefine the dataset?) happens if there is no snapshot on the destination (backup pool), and does not happen if there are snapshots (maybe it helps that they are compatible between the two hosts, as well).Or in more detail: