From owner-freebsd-fs@freebsd.org Fri Feb 26 11:16:22 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A2D1AB41BA for ; Fri, 26 Feb 2016 11:16:22 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.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 0C8861DCE for ; Fri, 26 Feb 2016 11:16:21 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.96] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id 601B59DC95A; Fri, 26 Feb 2016 12:07:18 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: ZFS receive and attributes, proposing some changes. was Re: ZFS full system backup hoses the backup host. From: Borja Marcos In-Reply-To: <0ae0e3ab-6ad1-4ae2-9ee9-a7d993088a01@email.android.com> Date: Fri, 26 Feb 2016 12:07:17 +0100 Cc: Zaphod Beeblebrox , freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: References: <0ae0e3ab-6ad1-4ae2-9ee9-a7d993088a01@email.android.com> To: =?utf-8?Q?Karli_Sj=C3=B6berg?= X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:16:22 -0000 > On 26 Feb 2016, at 05:56, Karli Sj=C3=B6berg = wrote: > What have other people done to get around this and/or can we either = put in > an "ignore properties" on receive flag or a -R on send that doesn't = send > them? (I removed freebsd-hackers as this discussion belongs in freebsd-fs) The possibility of replacing options in the receive command would be = most useful here. Ideally it should be done atomically with the receive.=20 For example: Imagine a replication system. It would be something like = this: - Make the first snapshot - Send it | receive it with -u (you don=E2=80=99t want it mounted) - Set the destination dataset=E2=80=99s canmount property to =E2=80=9Cnoau= to" - And, periodically - Make new snapshot - Send it incrementally - etc etc However, there is a race condition here. If your replication = program/script crashes, or it stops for whatever reason between the first send and the =E2=80=9Cset canmount=E2=80= =9D (or you reboot the destination server) you end up with a time bomb. Despite being received with the -u flag, if = you boot it will be mounted automatically. If you are replicating the root filesystem (or anything = mounted on an important system directory) you are dead :) To avoid this kind of problems, two options come to my mind, from least = desirable/useful/consistent to better (in my opinion) 1) Have some kind of force-inherit attribute on a dataset which forces = children=E2=80=99s mountpoint to go below it. Example: when replicating server1=E2=80=99s datasets, I send = them below to pool/server1_copies. If I set mountpoint=3Dforce_child (or something similar) for = pool/server1_copies, anything received under it would have the mountpoint changed, adding the mountpoint of = pool/server1_copies to it. Imagine I am replicating the /usr filesystem of server1, which = is pool_server1/usr, with the mountpoint /usr. The destination would have the mountpoint = /pool/server1_copies/usr. This at least avoids the unintended mountpoint overwrite = problem, which is not bad. And this possibility can be useful, but it=E2=80=99s not a very clean solution. 2) Adding an option to =E2=80=9Czfs receive=E2=80=9D so that properties = can be changed for the received dataset *atomically*. The race condition is avoided if I can specify an option to zfs = recv, something like -O canmount=3Dnoauto.=20 Actually, there are some changes I would make, not just for this = particular case, which will not break functionality and will make ZFS safer to use and easier to handle, = especially when replicating datasets. 1) Enhancing =E2=80=9Czfs recv=E2=80=9D with the possibility of changing = options and holds atomically.=20 - Changing options: -O option=3Dvalue -O option=3Dvalue - Adding holds: -h holdname When using snapshots to replicate datasets you must be careful = not to delete the last replicated snapshot accidentally, or you can lose the ability to do an incremental = send, forcing a full one. Holds help to prevent this. And if using them it would be very useful to have the last = snapshot properly protected in the destination dataset as well. Again, it should be done ATOMICALLY. Same applies to dataset properties, if only for the outright = dangerous combination of the canmount/mountpoint properties. Once more, we want this to be done ATOMICALLY with = the zfs recv.=20 2) Adding the possibility of specifying =E2=80=9Cdefault=E2=80=9D or = =E2=80=9Cinherit=E2=80=9D for the mountpoint property. When a dataset is created, the default mountpoint is = pool/dataset_name unless a different value is specified. A value of =E2=80=9Cdefault=E2=80=9D would set the dataset=E2=80=99= s mountpoint back to pool/=E2=80=A6/dataset_name, and =E2=80=9Cinherit=E2=80= =9D could=20 set the mountpoint to the "parent=E2=80=99s = mountpoint=E2=80=9D/dataset_name. These two options can be very useful when using zfs send/zfs = recv to keep replicas as a backup, but I think they can be useful in other situations.=20 What do you think? In my opinion these additions won=E2=80=99t break = functionality and they are worthwhile if only for making replication safer/more useful. Best regards, Borja. =09