Ability to reset a zfs clone or rebase on newer snapshot

iFrancisMe commented 6 months ago

Describe the feature would like to see added to OpenZFS

It would be nice to be able to reset a ZFS clone back to its original state based on the original snapshot it was cloned from or to be able to update an existing clone to that of a newer snapshot of origin dataset.

How will this feature improve OpenZFS?

If, for instance, I have a dataset being used as a template for a VM, and I then make several clones based off a snapshot. It would save a lot of time and effort not having to destroy and re-clone them if I needed to rollback several clones and did not have individual snapshots on the cloned datasets. Conversely, if I update the template with patches and whatnot, it would be great if I can somehow sync or update all the cloned datasets to the newest snapshot of the template. Again, this would save me from having to destroy all of the clones just to re-clone them.

Additional context

It seems that the only way currently to rollback a cloned dataset is to make a snapshot of the cloned dataset right after the cloning, which would allow me to, at least, reset the dataset back to its original cloned state. However, there does not seem to be a way to update the cloned dataset to a newer snapshot state of the original dataset. I have tried zfs send and receive, but it returns a message that the most recent snapshot does not match incremental source. So, it seems that the only way to manage my VMs running on cloned datasets is to update them individually or destroy all my cloned datasets and recreate them.

I may not understand correctly, but it seems that a clone is simply some kind of reference to the original dataset's snapshot. Would it be overly complicated to add the ability to change this reference to another snapshot or reset the clone's state back to the original reference? Obviously, this would destroy anything changed on the cloned dataset.

Alternatively, I know I can just zfs send / receive my initial "clones" for lack of a better word and just not use cloning. I can then continue to update the destination datasets incrementally. However, this does duplicate a lot of data and is slow at getting the initial replication.

It seems that cloning was intended more for data recovery than for branching into parallel workloads.

rincebrain commented 6 months ago

I believe something like: zfs promote my/clone zfs rollback my/clone@snapshot zfs promote my/original

would probably do the thing you desire, but I haven't tried it.

iFrancisMe commented 6 months ago

OK, I will give this a shot. However, something like self-updating clones could be pretty interesting. Anyway, I will try this out. Thank you. On Friday, February 9, 2024 at 12:14:25 AM PST, Rich Ercolani @.***> wrote:

I believe something like: zfs promote my/clone zfs rollback @.*** zfs promote my/original

would probably do the thing you desire, but I haven't tried it.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

rincebrain commented 6 months ago

I imagine you could try building something on top of the concepts used for the -o origin= functionality, maybe, but that'd get really gross to figure out the logistics of really quickly, I think...

dandudikof commented 6 months ago

Second this request (clone rollback). rollback to a hidden dataset@origin would be ideal.

iFrancisMe if you are using qemu-KVM qcow2 has (thin provisioning - disk image chains) that support rebasing , better suited to the task of managing VM images.

zfs can do basic clones of a original base and a linear progress only. (zfs can only destroy and recreate based on new base)

https://techpiezo.com/linux/use-and-implementation-of-backing-file-and-snapshot-in-qemu-kvm/ https://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html https://www.libvirt.org/kbase/backing_chains.html

openzfs / zfs