Date: Thu, 29 Apr 2010 20:20:32 +0300 From: Andriy Gapon <avg@freebsd.org> To: Artem Belevich <fbsdlist@src.cx> Cc: freebsd-fs@freebsd.org Subject: Re: few ideas for zfsloader Message-ID: <4BD9BFE0.90707@freebsd.org> In-Reply-To: <t2jed91d4a81004290937y1799630cp85be2a6515c1f921@mail.gmail.com> References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org> <t2jed91d4a81004290937y1799630cp85be2a6515c1f921@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 29/04/2010 19:37 Artem Belevich said the following: > Perhaps we can hijack vdev's boot block header and/or boot block > itself for these purposes. It's currently unused, according to ZFS > spec. I think that boot block is (can be) partially used by our zfsboot when a whole disk is dedicated to ZFS (i.e. no partitioning). E.g. see: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg103774.html The idea is fine in general. It's having to deal with multiple vdevs for a pool with complex topology is what can get messy. But I haven' given any real thought to this yet. If you come up with a design please share. Thanks! > See chapters 1.3.2 and 1.4 in ZFS on-disk format: > http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf Yep, have it on my (virtual) desk :-) > > On Thu, Apr 29, 2010 at 9:18 AM, Andriy Gapon <avg@freebsd.org> wrote: >> 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 >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD9BFE0.90707>