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

Wed Feb 25 09:35:16 UTC 2015

On Feb 24, 2015, at 6:44 PM, Steven Hartland wrote:

> Bookmarks?

If you mean using bookmarks rather than snapshots, it's a lean solution but with some shortcomings.
Bookmarks are fine if you just want to keep a copy of the data. And it can save a lot of room, of course it's still
compatible with replication to multiple targets, etc.

But replication with snapshots has an advantage. You have the option to copy not just data changes between
a bookmark and a snapshot, but also all the intermediate snapshots in between. If  you keep
some automated snapshot policy with the purpose of keeping recovery points (a Time Machine of sorts), bookmark
replication won't keep all that information on the target, or at the very least it will require the replication tool to work snapshot
by snapshot. With incremental snapshot replication you can use -I to send an incremental stream including intermediate snapshots.

Snapshots, compared to bookmarks, make replication code simpler, it doesn´t need to be explicitly "aware" of other snapshot management
being used concurrently.

Apart from this not so particular case, anyway in my opinion holds in their present state are an incomplete feature. Their usefulness is severely
limited by the potential to suffer a race condition between a snapshot creation and placing a hold on it. Why can user properties, several, 
even, be set atomically with a dataset or snapshot creation? Exactly the same reasons apply to holds. Actually, holds in their present state
are, in my opinion, the poisoned candy. Sweet to lure the unsuspecting programmer to use them and suffer a race condition.

Of course you can resort to recipes such as creating a snapshot with a temporal name, place a hold and rename it afterwards in order to protect
it as long as you keep some strict naming discipline, but it won't be as foolproof.

I was wrong with the "-h hold,hold2..." and I see that it should be "-h hold1 .. -h holdN" instead, in the same way as user properties. Actually,
altough this will prove much harder as the send/receive format is supposed to be frozen, holds should be sent along with the replication
stream. Or at the very least it would be nice if "zfs receive" could place a hold on the received snapshot.

And I was wrong on mentioning "create", sorry. Holds don't apply to datasets.

So, to summarize the  changes proposed:

zfs snap [-h hold] would create a hold atomically with snapshot creation, much like [-o property]. Multiple holds would be specified with multiple
-h options.

zfs send [-h] would make the stream contain holds information, working in the same way as "-p". Extending -R to encompass holds may look like
a good thing, but it  can be more problematic, as it would change its behavior, I would rather require the user to specify -h in order to explicitly
send the holds.

zfs  receive [-h hold] would be a ugly kludge in case it wasn't possible to send holds as part of a replication stream. But it still would offer
the possibility of atomic protection of a just received snapshot. 

I've been looking at the code and it's not that hard, although it will require some sugery down to the ioctl level!

Anyway, should I take this proposal to the ZFS mailing lists, or are there enough of the relevant members lurking here? A change such as this
one should be done for all the ZFS implementations.

Cheers,

Borja.

that a feature such as the holds is per se incomplete when you can suffer a race condition
when creating a snapshot and placing a hold on it. Why was it decided that properties, several even, could be added atomically with 

 can properties be applied atomically with a snapshot creation? Exactly for the
same reason.

as it can coexist with your manual snapshot management (for example, doing a snap right before an upgrade in order
to have a recovery opton) and incremental replication of snapshots offers the possibility of replicating all the snapshots
in between. 

:

First, imagine that I have two servers: the active and the reserve at a remote location and I am 

> 
> 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"
> 
> _______________________________________________
> 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"