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

Send/Receive Bookmarks #16756

Open
Haravikk opened this issue Nov 14, 2024 · 3 comments
Open

Send/Receive Bookmarks #16756

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

Comments

@Haravikk
Copy link

Haravikk commented Nov 14, 2024

Describe the feature would like to see added to OpenZFS

I would like to see the addition of a flag to zfs send to also send bookmarks, and a corresponding flag for zfs receive to receive/recreate them (otherwise it will ignore them).

This will require zfs send to transfer the bookmark in a way that zfs receive can set the correct createtxg value (since these will differ between sender/receiver) for the new bookmark.

Timing

Depending upon how easily a bookmark can be recreated on the receiving side, it may not be possible to send all bookmarks in an incremental send stream – this is because a bookmark could be created against an earlier snapshot that no longer exists. In such cases it's probably best to just issue a warning and continue, as there's nothing that can be done about it.

How will this feature improve OpenZFS?

Bookmarks can be extremely useful in managing ZFS without the overhead of snapshots, but currently they are not transferred even in a full replication stream, so it isn't possible to fully clone an existing pool with bookmarks without also running a script to recreate them (which may not even be possible if the original snapshots are gone).

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

amotin commented Nov 14, 2024

The whole point of bookmark is to point the dataset state for purposes of replication without holding actual data as done by snapshots. So bookmarks still coexisting with snapshots should be trivial to replicate, but I am not sure they are really useful in that case, since the expected workflow includes (possible) snapshot deletion to free the space after creating bookmark. If the snapshot was deleted though, replication of such bookmark would probably means sending first all the changes before the bookmark, then making receiving side to commit txg to create the bookmark at that state and then send changes after the bookmark. Seems like it should be possible, just needs some work.

@Haravikk
Copy link
Author

Yeah, would it perhaps make sense to split into separate stages?

First send bookmarks that have corresponding snapshots, since this is the simplest case – in this event "orphan" bookmarks (no snapshot) would be skipped with a warning. Then handling of orphan bookmarks could be added later?

@amotin
Copy link
Member

amotin commented Nov 14, 2024

It would be unpredictable and confusing to users. And proper implementation would cover it also.

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