Date: Tue, 24 Feb 2015 20:57:52 +0100 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-fs@freebsd.org Subject: Re: Proposal: enhancing zfs hold, atomic holds on create, snap and receive Message-ID: <355cc6d42f85b8aaff3ab6950b93c990@mailbox.ijs.si> 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
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 :) >>=20 >> I''ve been doing some incremental replication work with ZFS, and I am=20 >> using holds to prevent user errors. >> When someone destroys the wrong snapshot, a dataset must be sent=20 >> wholly beacuse it's no longer >> possible to perform an incremental send. A hold can prevent it,=20 >> marking the snapshot as "critical for incremental >> replication". Of course holds are even better as you can assign=20 >> several labelled holds >> to a single snapshot, so that each hold can represent a different=20 >> reason to keep it. >>=20 >> But there's a missing feature which would make them as perfect as they= =20 >> can get: holds >> are somewhat of an afterthough, a second class citizen compared to=20 >> properties and, unlike properties, >> you can't (for example) place a hold atomically on a snapshot when=20 >> creating it. >>=20 >> ZFS has a nice feature that allows you to create an object (snapshot=20 >> or dataset) and, *atomically* assign a property to it. >> The same feature applies to create and clone, of course, although it=20 >> doesn=C2=B4t to receive, which might be useful. >>=20 >> So, the proposal is to add a "-h hold1,hold2,..holdN" option to "zfs=20 >> 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=20 >> 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! >> Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?355cc6d42f85b8aaff3ab6950b93c990>