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

Pseudo Snapshots #16749

Open
Haravikk opened this issue Nov 13, 2024 · 2 comments
Open

Pseudo Snapshots #16749

Haravikk opened this issue Nov 13, 2024 · 2 comments
Labels
Type: Feature Feature request or new feature

Comments

@Haravikk
Copy link

Haravikk commented Nov 13, 2024

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

  1. Dataset contains a snapshot tank/foo@current, the dataset has not been changed since.
  2. zfs snapshot tank/foo@new is created as a "pseudo snapshot" (a bookmark referencing tank/foo@current).
  3. All operations that require a snapshot will silently swap @new for @current.
  4. 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:

zfs snapshot -r tank/foo@replicate
zfs send -R tank/foo@replicate | zfs receive -F target

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.

@Haravikk Haravikk added the Type: Feature Feature request or new feature label Nov 13, 2024
@amotin
Copy link
Member

amotin commented Nov 13, 2024

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.

@Haravikk
Copy link
Author

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?

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

2 participants