From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 19:58:00 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 187B5D52 for ; Tue, 24 Feb 2015 19:58:00 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 BBB25E02 for ; Tue, 24 Feb 2015 19:57:59 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3ks9zR4vRFz6j for ; Tue, 24 Feb 2015 20:57:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1424807872; x=1427399873; bh=StT zqZccJGkd9bZsx2gCO9llUyABU7VIjzGkAt/jZag=; b=Cyqar7BZu2vW5En5jb0 ELERXHT6xIp+94kgOWHKDNFIzKx/c34sBOThVAFYE8cn31tzBJdY17esyoc4xJfS E8nFrEzefGgXsClDmC/NUUxqFpdpu1m9ozupbdUfgsEL5M8BiF4cxS3G7WY1YlqG vF4Ql91lLUKmygoPqJAAo+T8= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id SzPkvbjbNnk1 for ; Tue, 24 Feb 2015 20:57:52 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 24 Feb 2015 20:57:52 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3ks9zN1dTnzsW for ; Tue, 24 Feb 2015 20:57:52 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 24 Feb 2015 20:57:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2015 20:57:52 +0100 From: Mark Martinec To: freebsd-fs@freebsd.org Subject: Re: Proposal: enhancing zfs hold, atomic holds on create, snap and receive Organization: J. Stefan Institute In-Reply-To: <54ECB88C.5060305@multiplay.co.uk> References: <54ECB88C.5060305@multiplay.co.uk> Message-ID: <355cc6d42f85b8aaff3ab6950b93c990@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.0 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 19:58:00 -0000 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.