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>
index | next in thread | raw e-mail
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.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E67A7F73-0930-41DB-B134-B8E4C6E31AF8>