Feature #3568
open
Add a ZFS dataset attribute to disallow creation of snapshots, ever
0%
Description
(I think I mentioned the idea a number of times, but can't find it as a registered RFE - so here goes, sorry if dup)
PROBLEM
There are a number of cases when a user does not want to create snapshots of certain datasets - for example, rpool/swap or rpool/dump, as well as any scratch directories he might create with explicit intention of not wasting disk space after files are removed.
Part of the "problem" comes with zfs-auto-snapshots service (aka TimeSlider), which can be disabled by adding its properties to certain datasets. However, it is not inconvenient to do, before a drastic action, something like "zfs snapshot -r rpool@snapname" - which would ignore the time-slider attributes of course and snapshoot everything, including dump and swap (and boost their reservations, among other drawbacks).
PROPOSAL
The proposed idea is that an optional attribute is added to fs and zvol datasets, for example "nosnaps", with default being "off".- If enabled "on", it causes "zfs snapshot" to ignore this dataset. An option (either in "nosnaps" value like "quiet"/"warn", or a pool-wide toggle like "listsnapshots" today) can cause the ignoration to be quiet or to produce a warning in the "zfs snapshot" output - either way, not causing a fatal condition.
- If the current dataset has descendands which overrode the "nosnaps" value to enable snapshots - they should be honored and snapshotted (in case of recursive snapshots of the whole pool's root, etc.)
- For bonus points, recursive removal of snapshots should still succeed - even if a nosnaps=on dataset is in the way. This should either be built into "zfs destroy -r" (to consider "nosnaps" current value? what if it changed since?) or perhaps by causing recursive "zfs snapshot -r" requests to create, if child datasets exist, dummy snapshots with matching name and zero space consumption (i.e. taking the last snapshot's closing TXG and referencing it as the "fake snapshot's" TXG range, or 0..0 if none - maybe "0" should be the dataset's creation time). If a solution with such "fake snapshots" is chosen, there should be some way to comment their nature to both system and live user.
- Presence of older snapshots of the dataset should be irrelevant if "nosnaps=on" is set - it is just that new "proper snapshots" (see ideas above about catering for recursive removal) won't be created, and blocks created/updated after setting this flag and then removed from dataset are instantly released into the pool's free space.
Updated by Jim Klimov over 10 years ago
- It might not have been clear - the attribute can of course be later disabled (explicitly or by inheritance), returning us to usual "zfs snapshot" processing we have today.
- recursive "zfs send"'ing of datasets with this option should work if some snapshot in the dataset exists and matches the send request (much similar to "zfs destroy -r" processing). The current value of source's "nosnaps" should be set on the resulting target dataset.
More thought is needed about corner cases below. Perhaps answers to these questions require separate (comma-separated?) values of the attribute, like "nosnaps=warn,noclone,send" with anything except "off" being an "on"?..
Uncertainties thought of so far:- how should "zfs send" interact with inherited (implicit) values of source dataset's "nosnaps" - should these values be transferred or ignored?
- how should "zfs clone" interact with the value (likely, the source snapshot - if it exists - references a "nosnaps=off" value; should the current one be replicated during cloning?)
- if recursive "zfs send" encounters a dataset without snapshots and with "nosnaps=on", should it skip over the dataset completely or pass onto the target the commands needed to create a similarly configured dataset? i.e. when cloning an rpool to spawn a new machine - should swap and dump be recreated on target?
- What about the same procedure used to just back up the rpool and not waste space/reservations on backup media?
- What about the cases when the dataset with "nosnaps=on" has children with explicit "nosnaps=off" or otherwise enabled replication? - somehow, they should have a parent dataset created on the target..
Updated by Jim Klimov over 10 years ago
Ah, I found my older suggestion on the same subject in RFE #996. I guess that old one can now be disregarded as a duplicate.
- One useful idea from there, which can be implemented along with this current and much more detailed issue by using comma-separated "nosnaps" values, is to skip over creation of snapshots of certain datasets ONLY when recursing from their parents - but allow creation of the snapshot if the dataset is an explicit target of "zfs snapshot" invokation.