Proposal: enhancing zfs hold, atomic holds on create, snap and receive

Steven Hartland killing at multiplay.co.uk
Tue Feb 24 17:52:59 UTC 2015


Bookmarks?

On 24/02/2015 16:38, Borja Marcos wrote:
> Hi :)
>
> I''ve been doing some incremental replication work with ZFS, and I am using holds to prevent user errors.
> When someone destroys the wrong snapshot, a dataset must be sent wholly  beacuse it's no longer
> possible to perform an incremental send. A hold can prevent it, marking the snapshot as "critical for incremental
> replication". Of course holds are even better as you can assign several labelled holds
> to a single snapshot, so that each hold can represent a different reason to keep it.
>
> But there's a missing feature which would make them as perfect as they can get: holds
> are somewhat of an afterthough, a second class citizen compared to properties and, unlike properties,
> you can't (for example) place a hold atomically on a snapshot when creating it.
>
> ZFS has a nice feature that allows you to create an object (snapshot or dataset) and, *atomically* assign a property to it.
> The same feature applies to create and clone, of course, although it doesn´t to receive, which might be useful.
>
> So, the proposal is to add a "-h hold1,hold2,..holdN" option to "zfs snap" and ideally zfs receive, so that a  hold would be
> placed atomically with the snapshot creation.
>
> This feature would prevent some possible race conditions in snapshot management, which would make them much more useful.
> I imagine that the -o option as added with the same purpose.
>
> What do you think?
>
>
> Thanks!
>
>
>
>
> Borja.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"



More information about the freebsd-fs mailing list