From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:18:54 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 387AE106577C for ; Thu, 29 Apr 2010 16:18:54 +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 E93F58FC20 for ; Thu, 29 Apr 2010 16:18:52 +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 TAA13213 for ; Thu, 29 Apr 2010 19:18:51 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BD9B16A.10606@freebsd.org> Date: Thu, 29 Apr 2010 19:18:50 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B9FD6E0.5000303@icyb.net.ua> In-Reply-To: <4B9FD6E0.5000303@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 16:18:54 -0000 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