Fix parser for root (only) dataset names - investigate #619
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
jimklimov
changed the title
@check-spelling-bot ReportUnrecognized words, please review:
Previously acknowledged words that are now absentaix Autotools bashisms CBuilder Cwd cygwin DBD ev Fcntl fh forkcall gh Gregy gz Ip JB JBERGER LEONT Mkbootstrap nf nh oi Pipely qq qw RCAPUTO README rr rw SUBDIRS SZ Ubuntu ve VOS wu wx xargs xf yy ZLSome files were were automatically ignoredThese sample patterns would exclude them: You should consider adding them to: File matching is via Perl regular expressions. To check these files, more of their words need to be in the dictionary than not. You can use To accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands... in a clone of the null repository |
jimklimov
changed the title
…a pool [oetiker#585] Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…Set [oetiker#585] Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…) and splitDataSetSnapshot() [oetiker#585] Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…ent is actually a "dataset@snapname", return an undef snapname in the array if not [oetiker#585] Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…etiker#585] Signed-off-by: Jim Klimov <jimklimov@gmail.com>
jimklimov
force-pushed
the
fix-parser-rootds-investigate
branch
from
097c794
to
3c7d300
Compare
oetiker
approved these changes
Jan 9, 2024
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.
Follows up from #585 and a Gitter discussion https://matrix.to/#/!XZJhhFzueFpkcSXLHR:gitter.im/$gVcghYo80LIz2zIdyJQyfxRYJkyb07mQjoB5bGH5zTU?via=gitter.im&via=inf.ethz.ch&via=matrix.org (and later posts during the day)
The crux of it is that
znapzendv0.21.2 (current release) got confused when a backup schedule was defined on a root dataset of a pool AND the customtsformatincluded colons to separate hours-minutes-seconds:So a request to snapshot a local
bpooldataset asbpool@znapzend-auto-2024-01-08T10:22:13Zgot interpreted by the generic routine asuser=bpool,host=znapzend-auto-2024-01-08T10,dsname=22:13Zand an absent snap. The latter part also got further parsed for the subsequent command intohost=22anddsname=13Z, it seems.This visibly strikes in
sub createSnapshot {...},sub destroySnapshots {...}and probably other consumers ofsub $splitHostDataSet.If the "DST" definition remains (per help/man) as
[[user@]host:]datasetwheredatasetis fixed for DST but may bedsname[@snap]for general parsing (andsnapmay have some but not all sorts of funny characters) -- we don't really have good criteria (for regex or beside it) to tell apart auser@hostfrom partialdataset@snapstrings, in some cases, it seems.There are various ideas in that thread that can be pursued as separate PRs. This one lays the foundations for such pursuits, by adding a few run-time sanity checks (e.g. to avoid destructive actions with bogus values), and some self-test code to gauge success of different solution attempts. A large helper in this effort is the
t/znapzend-lib-splitter.tscript which calls whatever implementations we have inZFS.pmand runs them against a matrix of known remote, dataset and snapname strings (concatenated into what can be seen in production from configs and ZFS queries), to see if they get parsed back properly.