Date: Thu, 29 Apr 2010 19:18:50 +0300 From: Andriy Gapon <avg@freebsd.org> To: freebsd-fs@freebsd.org Subject: Re: few ideas for zfsloader Message-ID: <4BD9B16A.10606@freebsd.org> In-Reply-To: <4B9FD6E0.5000303@icyb.net.ua> References: <4B9FD6E0.5000303@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 16/03/2010 21:07 Andriy Gapon said the following: > 2. Currently nextboot functionality doesn't work properly with ZFS because there > is no RW support in zfsloader. Adding that support seems to be quite hard given > the transactional nature of ZFS, checksums, compression and what not. > Here's an alternative idea: honor nextboot.conf only if boot filesystem has a a > special property set on it, for example org.freebsd:nextboot. > Then all we need is to flip the property off. > Although doing this is still not trivial it should be simpler than filesystem RW > support. ZFS properties do, in fact, have the same nature as regular file data. So, changing a property value (whether filesystem or pool) requires practically the same level of write support as modification of a file. And this seems to be quite complex to do in loader; updating all necessary vdevs, doing checksums, transactions, etc. So, right now, I do not see a way to properly support nextboot with ZFS. We probably should emit some warning when nextboot.conf is created on ZFS that there will not be automatic recovery if kernel boot fails. Some really weird alternative ideas: 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD) 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf and it is honored until the timestamp expires. But I won't seriously consider these. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD9B16A.10606>