You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature would like to see added to OpenZFS
Currently if a dataset has a snapshot, and has not been changed since that snapshot was created, creating a new snapshot is registered as a change to that dataset, which interferes with incremental send operations.
However these snapshots don't really represent any actual changes, so it may make more sense to have them instead become a "pseudo snapshot" – essentially a bookmark that looks and behaves like a snapshot for ZFS commands.
In essence, any command given a pseudo-snapshot will either use at as a bookmark as normal (if it supports them), or swap it for the "root" snapshot that it is identical to/was created from.
When a snapshot is to be destroyed, ZFS will check to see if it has any corresponding "pseudo snapshots" – if it does, instead of destroying the snapshot it will instead be renamed to replace the first pseudo snapshot, whose internal bookmark is then removed. If there are multiple "pseudo snapshots" they will continue to be proxies/aliases of the "root" snapshot as normal.
Example
Dataset contains a snapshot tank/foo@current, the dataset has not been changed since.
zfs snapshot tank/foo@new is created as a "pseudo snapshot" (a bookmark referencing tank/foo@current).
All operations that require a snapshot will silently swap @new for @current.
zfs destroy tank/foo@current will not destroy the snapshot, instead it will be renamed to @new and the internal bookmark for @new is discarded.
At any time an incremental send can be performed to tank/foo without encountering issues, as it is still effectively unchanged throughout.
Compatability
Internally the "pseudo snapshot" should just be a bookmark with the same createtxg and guid as its "parent" snapshot, plus a means of identifying it as a pseudo snapshot, such as a naming convention or flag that is safe for older versions of ZFS to ignore.
For compatibility reasons, "pseudo snapshots" should always be checked for a "parent" snapshot – if none is found, the pseudo snapshot is treated in all respects as an ordinary bookmark (no special behaviours).
This is because to earlier versions a "pseudo snapshot" will simply appear as a regular bookmark, and the "parent" snapshot can be destroyed separately, resulting in orphaned "pseudo snapshots".
How will this feature improve OpenZFS?
It will make it possible to create recursive snapshots on a pool without having to worry about how its snapshots are normally handled, or if creating a snapshot will break incremental sends to that pool.
As a result, it should make it a lot easier to replicate pools that are currently in use by doing the following:
Without having to worry about what the existing snapshot scheme looks like, since the recursive snapshot(s) will either be true snapshots or pseudo snapshots as necessary, avoiding any disruption to consistency for sending to the same pool.
Additional Context
I'm not happy with the term "pseudo snapshot" but it's the best I could come up with. I considered "cloned snapshots" but I think that could get confusing.
The text was updated successfully, but these errors were encountered:
I think now each snapshot is always created pointing at the current transaction group. So unless you create several snapshots in one command, I think they will point to different txgs and won't be identical. I wonder what is the actual difference between them other than txg number and is it avoidable? I wonder what would happen if we always point snapshots not to the current txg, but to a txg of the last change. One effect I can see is that we would not be able to tell that recursive snapshots were actually synchronous, they would look like they are not, but can't guess others. But I haven't been in that area deep lately, so just don't remember details.
If it's possible to create duplicate snapshots on an unchanged dataset without the new snapshot itself appearing as a new transaction then that would be even better.
Only issue could be if any code assumes snapshots must have different txgs, such as in zfs send -I or similar? But if they don't, then it should mean no issues with compatibility?
Describe the feature would like to see added to OpenZFS
Currently if a dataset has a snapshot, and has not been changed since that snapshot was created, creating a new snapshot is registered as a change to that dataset, which interferes with incremental send operations.
However these snapshots don't really represent any actual changes, so it may make more sense to have them instead become a "pseudo snapshot" – essentially a bookmark that looks and behaves like a snapshot for ZFS commands.
In essence, any command given a pseudo-snapshot will either use at as a bookmark as normal (if it supports them), or swap it for the "root" snapshot that it is identical to/was created from.
When a snapshot is to be destroyed, ZFS will check to see if it has any corresponding "pseudo snapshots" – if it does, instead of destroying the snapshot it will instead be renamed to replace the first pseudo snapshot, whose internal bookmark is then removed. If there are multiple "pseudo snapshots" they will continue to be proxies/aliases of the "root" snapshot as normal.
Example
tank/foo@current
, the dataset has not been changed since.zfs snapshot tank/foo@new
is created as a "pseudo snapshot" (a bookmark referencingtank/foo@current
).@new
for@current
.zfs destroy tank/foo@current
will not destroy the snapshot, instead it will be renamed to@new
and the internal bookmark for@new
is discarded.At any time an incremental send can be performed to
tank/foo
without encountering issues, as it is still effectively unchanged throughout.Compatability
Internally the "pseudo snapshot" should just be a bookmark with the same
createtxg
andguid
as its "parent" snapshot, plus a means of identifying it as a pseudo snapshot, such as a naming convention or flag that is safe for older versions of ZFS to ignore.For compatibility reasons, "pseudo snapshots" should always be checked for a "parent" snapshot – if none is found, the pseudo snapshot is treated in all respects as an ordinary bookmark (no special behaviours).
This is because to earlier versions a "pseudo snapshot" will simply appear as a regular bookmark, and the "parent" snapshot can be destroyed separately, resulting in orphaned "pseudo snapshots".
How will this feature improve OpenZFS?
It will make it possible to create recursive snapshots on a pool without having to worry about how its snapshots are normally handled, or if creating a snapshot will break incremental sends to that pool.
As a result, it should make it a lot easier to replicate pools that are currently in use by doing the following:
Without having to worry about what the existing snapshot scheme looks like, since the recursive snapshot(s) will either be true snapshots or pseudo snapshots as necessary, avoiding any disruption to consistency for sending to the same pool.
Additional Context
I'm not happy with the term "pseudo snapshot" but it's the best I could come up with. I considered "cloned snapshots" but I think that could get confusing.
The text was updated successfully, but these errors were encountered: