Date: Wed, 25 Feb 2015 10:35:10 +0100 From: Borja Marcos <borjam@sarenet.es> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: Proposal: enhancing zfs hold, atomic holds on snap and receive Message-ID: <A39FA4AE-65AC-4E4D-8B00-EB65171D91C4@sarenet.es> In-Reply-To: <54ECB88C.5060305@multiplay.co.uk> References: <E67A7F73-0930-41DB-B134-B8E4C6E31AF8@sarenet.es> <54ECB88C.5060305@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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=B4t 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,=20 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.=20 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. =20 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=20 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.=20 : First, imagine that I have two servers: the active and the reserve at a = remote location and I am=20 >=20 > On 24/02/2015 16:38, Borja Marcos wrote: >> Hi :) >>=20 >> 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. >>=20 >> 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. >>=20 >> 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=B4t to receive, which might be useful. >>=20 >> 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. >>=20 >> 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. >>=20 >> What do you think? >>=20 >>=20 >> Thanks! >>=20 >>=20 >>=20 >>=20 >> Borja. >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A39FA4AE-65AC-4E4D-8B00-EB65171D91C4>