From owner-freebsd-fs@FreeBSD.ORG Tue Mar 16 19:07:16 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 304D4106566C for ; Tue, 16 Mar 2010 19:07:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7A54A8FC21 for ; Tue, 16 Mar 2010 19:07:15 +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 VAA27570 for ; Tue, 16 Mar 2010 21:07:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B9FD6E0.5000303@icyb.net.ua> Date: Tue, 16 Mar 2010 21:07:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: 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: Tue, 16 Mar 2010 19:07:16 -0000 I have three crazy-ish ideas for zfsloader. Unfortunately, right now I am short on time and I am very short on ZFS knowledge to go for implementing them myself. 1. If vfs.root.mountfrom is not already set and there is no root mount entry in fstab then set vfs.root.mountfrom to "zfs:". This obviously requires being able to get properties of the current dataset (filesystem) and get the name from them. 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. 3. Currently ZFS boot chain lacks an ability to switch bootfs property of a pool. So, if a (new) boot environment is not quite bootable and bootfs points to it, then an alternative boot media (e.g. livecd) is needed to correct the situation. Implementing selection of a boot filesystem in ZFS boot chain seems like a hard task. Alternative idea: a new FreeBSD-specific pool property, nextbootfs. This property would designate a boot filesystem for the next boot and would be automatically reset by a boot loader at sufficiently early stage. If the next boot doesn't succeed, then we are back to the regular bootfs property, if it does succeed, then bootfs can be safely changed to the new value. -- Andriy Gapon