From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 17:20:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A62551065675 for ; Thu, 29 Apr 2010 17:20:38 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D0A3A8FC15 for ; Thu, 29 Apr 2010 17:20:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA14232; Thu, 29 Apr 2010 20:20:33 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BD9BFE0.90707@freebsd.org> Date: Thu, 29 Apr 2010 20:20:32 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Artem Belevich References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: few ideas for zfsloader X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:20:38 -0000 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 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