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

Recursive snapshot (zfs snapshot -r) exlusions #8443

Closed
baryluk opened this issue Feb 22, 2019 · 14 comments
Closed

Recursive snapshot (zfs snapshot -r) exlusions #8443

baryluk opened this issue Feb 22, 2019 · 14 comments
Labels
Type: Feature Feature request or new feature

Comments

@baryluk
Copy link

baryluk commented Feb 22, 2019

This is a wishlist for zfs snapshot -r command.

It would be great to add property on some datasets (com.sun:auto-snapshot=false or similar), that when combined with a flag to zfs snapshot (i.e. zfs snapshot -r -x), will create atomic set of snapshot of all datasets and descendent child, with exception of the ones with com.sun:auto-snapshot=false set or inherited from parent.

Use case is for automatic periodic snapshots. I.e. I do have my home directory contain about 30 datasets (some with custom compression, mirror, checksum, recsize, redund_md, quota, etc. settings). But there are two or three datasets I wish not to snapshot really (.cache, .steam and ZeroNetData), but rest should be snapshoted.

Right now I simply do this from crontab:

/usr/local/sbin/zfs snapshot -r "wctank4@daily_$(date --iso-8601=seconds | sed -e 's/\+/P/g')"

to snapshot entire pool and all datasets in the pool, which is very nice and easy to do.

Right now there is no easy way to do a recursive snapshot of pool or dataset and its childs, with exception, and do it atomically. Using zfs program is an option, but this makes the process WAY more complex, and doesn't allow me to do it atomically from the point of view of data stored in this datasets.

Basically zfs snapshot -r -x wctank4@ble would be equivalent to:

zfs snapshot $(zfs list -H -r -o com.sun:auto-snapshot,name wctank4 | awk '$1 !~ /false/ {print $2 "@ble";}' | tr '\n' ' ')

but nicer, less error prone (i.e. datasets with spaces in names or other special characters), more performant (when using big number of datasets, as zfs list need to sort list, but we do not need it), more reliable (there are limits in kernel of how many arguments you can pass to a program via argv) and available auto of the box.

Behaviour of zfs snapshot and zfs snapshot -r would be unaffected by the user property.

@bunder2015 bunder2015 added Type: Feature Feature request or new feature Missing Template labels Feb 22, 2019
@sdimitro
Copy link
Contributor

Hi @baryluk ,

The following sentence from your bug report picked my interest:

Even using zfs program, (which makes the process WAY more complex), doesn't allow me to do > it atomically from the point of view of data stored in this datasets.

Do you have a reproducible case where you snapshot datasets through a channel program and the snapshots are not atomically created together (or rollback together if there is a failure)?

If yes, then that would be a channel program bug and we would need to take care of it.

@baryluk
Copy link
Author

baryluk commented Feb 22, 2019

My reference to atomicity was in regards to actual consistency of data in snapshots itself, not all or nothing creation of them.

My understanding is (possibly wrong?), that if I do snapshot -r or snapshot a@x b@y, not only snapshot will be created atomically (all or nothing), but state of data in these snapshots will be consistent and taken at globally consistent timestamp for all of these snapshots.

@baryluk
Copy link
Author

baryluk commented Feb 22, 2019

My mistake then, however the remaining part of my statement, of it being not user friendly in general and pretty complex stands.

Updated my initial post.

@sdimitro
Copy link
Contributor

@baryluk

I agree that the proposed command (or some variation of it) would be more succinct than writing a channel program script.

The problem is there have been many requests of that nature over the years and many of them are conflicting. For example, some users may want zfs snapshot -r to create the snapshots as one transaction, while others may feel that it may be better to just create as many as you can until you hit an error to save some time because they have 100K+ datasets and other stuff going on in the system.

Another problem is that we have use cases (like the one mentioned in this issue) which are legitimate but would be hard to implement correctly while maintaining a clean and consistent interface across all zfs subcommands. By consistency I mean the lack of surprises like expecting -v to mean "verbose" or -r to mean "recursive" for all subcommands that they are implemented.

Finally from a developer's perspective, the amount of work needed as we add command options increases exponentially and testing gets trickier because we need to test all the different combinations of options (with some of them bound to be incompatible).

Since we can't envision all the different user needs that exist out there, we decided to provide the option of trading-off some operational-complexity for more power and flexibility with channel programs (zfs program). Note that this does not mean that requests like the one issued here should be dropped. If the issue is a common pain-point for many users out there we should definitely consider implementing it.

For your specific use case now, if you can't wait to see if the issue will ever get traction, I'd recommend going the channel program way for now as it should provide both the performance and the consistency that you need. If you need help writing such a script, the man page can be used as a reference. There is also an example of an atomic recursive dataset destroying script here with a few if statement examples for specific selection. Then, last but not least, the OpenZFS Slack channels.

@maxximino
Copy link
Contributor

How about supporting frequently-requested/generic-enough use-cases with a ZoL-provided set of channel programs?
such people can lookup in a manpage if there's something suitable and do zfs program pool /usr/share/zfs/channel-program-for-my-issue.zcp arg1 arg2 ?

@spaghettopazzia
Copy link

How does one join the OpenZFS Slack channels? I am reading a lot of these "join our Slack channel" all over the place but there is very little to no information on how to do it. Even the openzfs wiki "Newcomers" page suggests joining the channel as a "best way to reach us with questions", then you go to the slack website and find out "This team's administrator has not enabled email signups." and "Contact the workspace administrator for an invitation". I asked in the openzfs irc channel and no one seems to know how to join slack. It is very frustrating to feel invited in on the surface and then left out in practice.

@sdimitro
Copy link
Contributor

@spaghettopazia

You can download the Slack app and search for OpenZFS or join through the web interface in your browser from this link: https://openzfs.slack.com . If you still have issues feel free to reach out to me directly, so we don't go off topic on this thread.

@gmelikov
Copy link
Member

@sdimitro

 Don't have an account on this workspace yet? Contact the workspace administrator for an invitation 

Can we make OpenZFS slack work without invitation?

@sdimitro
Copy link
Contributor

@gmelikov Shoot! For some reason I thought it was open to everyone! I will ping the admins

allanjude pushed a commit to allanjude/zfs that referenced this issue Aug 12, 2019
Channel programs that many users find useful should be included with zfs
in the /contrib directory. This is the first of these contributions. A
channel program to recursively take snapshots of datasets with the
property com.sun:auto-snapshot=true.

Reviewed-by: Kash Pande <kash@tripleback.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Clint Armstrong <clint@clintarmstrong.net>
Closes openzfs#8443
Closes openzfs#9050
allanjude pushed a commit to allanjude/zfs that referenced this issue Oct 13, 2019
Channel programs that many users find useful should be included with zfs
in the /contrib directory. This is the first of these contributions. A
channel program to recursively take snapshots of datasets with the
property com.sun:auto-snapshot=true.

Reviewed-by: Kash Pande <kash@tripleback.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Clint Armstrong <clint@clintarmstrong.net>
Closes openzfs#8443
Closes openzfs#9050
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 24, 2019
Channel programs that many users find useful should be included with zfs
in the /contrib directory. This is the first of these contributions. A
channel program to recursively take snapshots of datasets with the
property com.sun:auto-snapshot=true.

Reviewed-by: Kash Pande <kash@tripleback.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Clint Armstrong <clint@clintarmstrong.net>
Closes openzfs#8443
Closes openzfs#9050
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 27, 2019
Channel programs that many users find useful should be included with zfs
in the /contrib directory. This is the first of these contributions. A
channel program to recursively take snapshots of datasets with the
property com.sun:auto-snapshot=true.

Reviewed-by: Kash Pande <kash@tripleback.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Clint Armstrong <clint@clintarmstrong.net>
Closes openzfs#8443
Closes openzfs#9050
tonyhutter pushed a commit that referenced this issue Jan 23, 2020
Channel programs that many users find useful should be included with zfs
in the /contrib directory. This is the first of these contributions. A
channel program to recursively take snapshots of datasets with the
property com.sun:auto-snapshot=true.

Reviewed-by: Kash Pande <kash@tripleback.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Clint Armstrong <clint@clintarmstrong.net>
Closes #8443
Closes #9050
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

7 participants
@baryluk @maxximino @sdimitro @gmelikov @bunder2015 @spaghettopazzia and others