Date: Fri, 26 Feb 2016 12:07:17 +0100 From: Borja Marcos <borjam@sarenet.es> To: =?utf-8?Q?Karli_Sj=C3=B6berg?= <karli.sjoberg@slu.se> Cc: Zaphod Beeblebrox <zbeeble@gmail.com>, freebsd-fs <freebsd-fs@freebsd.org> Subject: ZFS receive and attributes, proposing some changes. was Re: ZFS full system backup hoses the backup host. Message-ID: <C3EAA8F3-8EFA-450E-A4A3-A790EA2DA396@sarenet.es> In-Reply-To: <0ae0e3ab-6ad1-4ae2-9ee9-a7d993088a01@email.android.com> References: <CACpH0Me58jK%2BOz3PCqH93NEn=5V1SKwPGdku62sAVLVh%2BWxEeA@mail.gmail.com> <0ae0e3ab-6ad1-4ae2-9ee9-a7d993088a01@email.android.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 26 Feb 2016, at 05:56, Karli Sj=C3=B6berg <karli.sjoberg@slu.se> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3EAA8F3-8EFA-450E-A4A3-A790EA2DA396>