Date: Tue, 24 Feb 2015 17:38:29 +0100 From: Borja Marcos <borjam@sarenet.es> To: "freebsd-fs@freebsd.org Filesystems" <freebsd-fs@freebsd.org> Subject: Proposal: enhancing zfs hold, atomic holds on create, snap and receive Message-ID: <E67A7F73-0930-41DB-B134-B8E4C6E31AF8@sarenet.es>
next in thread | raw e-mail | index | archive | help
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.=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. 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. 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.=20 I imagine that the -o option as added with the same purpose. What do you think? Thanks! Borja.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E67A7F73-0930-41DB-B134-B8E4C6E31AF8>