From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 16:43:59 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A6FC957 for ; Tue, 24 Feb 2015 16:43:59 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BACC6372 for ; Tue, 24 Feb 2015 16:43:58 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 041B69DE0C7 for ; Tue, 24 Feb 2015 17:38:33 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Proposal: enhancing zfs hold, atomic holds on create, snap and receive Date: Tue, 24 Feb 2015 17:38:29 +0100 Message-Id: To: "freebsd-fs@freebsd.org Filesystems" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:43:59 -0000 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.=