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

[Mark Martinec]

Steven Hartland wrote:

> Bookmarks?

If only the sysutils/zxfer would put bookmarks to good use,
life would be easier (in presence of automatic snapshot management
like with zfs-snapshot-mgmt) ...

   Mark


> 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.