Date: Tue, 31 May 2011 14:36:08 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Arnaud Houdelette <tzim@tzim.net> Cc: freebsd-stable@FreeBSD.org Subject: Re: zfs-root and "safe" atomic updates Message-ID: <4DE4D2A8.7050006@FreeBSD.org> In-Reply-To: <a4dc7c5cc5e907c09e1baf8dab0d2156@tzim.net> References: <63454684d7d46c2ef76cfcc979500612@tzim.net> <4DDF8E02.4060108@FreeBSD.org> <a4dc7c5cc5e907c09e1baf8dab0d2156@tzim.net>
next in thread | previous in thread | raw e-mail | index | archive | help
on 27/05/2011 17:16 Arnaud Houdelette said the following: > On Fri, 27 May 2011 14:41:54 +0300, Andriy Gapon wrote: >> I am not aware of any plans to implement nextboot for zfs as it would >> require at >> least some write support for zpool and there is none (for boot code) >> at the moment. >> > > Could'nt the loader use a bit flag in the loader sector ? First, strictly speaking, the loader is an executable on a filesystem, there is no "loader sector". If we consider the earlier boot stages, various incarnations of boot2 like gptzfsboot or non-MBR part of zfsboot, then it gets interesting for multi-disk configurations. FreeBSD has its view of disks, but BIOS (which is used for disk access during boot) has its own different view of disks. So it's hard (or impossible) to do an auto-magic thing here. One option could be to force a user to use its superior knowledge of a system to explicitly specify which disk and which boot block should be used for nextboot-ish purposes. That, of course, would be prone to footshooting because of the human nature. For example, one could specify a wrong disk, boot, see that nothing changed, realize the mistake, specify correct disk, never clean out nextboot-ish data on the wrong disk, change boot order months later and get badly hurt. But it could also be argued that that approach would be better than nothing, which is the case for ZFS at the moment. > Nextboot (or something equivalent) missing is the sole thing keeping me from > removing ufs boot partition for remote servers. > >>> What do you think ? How do you address the problem ? >> >> I have some patches that allow to boot a different loader or a kernel from a >> different (non-bootfs) ZFS dataset: >> http://lists.freebsd.org/pipermail/freebsd-fs/2010-July/008976.html >> But that still requires access to zfs boot and/or loader command interface. > > Interesting though. Thanks. > Does the mentionned patch still works with latest 8-stable loader ? I've rebased the patch to the latest head: http://people.freebsd.org/~avg/zfsboot.diff > And do you still have to change vfs.root.mountfrom once currdev set ? That should already be included into the patch. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE4D2A8.7050006>