Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Apr 2012 23:21:02 +0200
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
Message-ID:  <20120422212102.GA66855@alchemy.franken.de>
In-Reply-To: <4F8999D2.1080902@FreeBSD.org>
References:  <4F8999D2.1080902@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 14, 2012 at 06:37:54PM +0300, Andriy Gapon wrote:
> 
> I would like to ask for a review and/or testing of the following three patches:
> http://people.freebsd.org/~avg/zfsboot.patches.diff
> 
> These patches add support for booting from an arbitrary filesystem of any
> detected ZFS pool.  A filesystem could be selected in zfsboot and thus will
> affectfrom where zfsloader would be loaded.  zfsboot passes information about
> the boot pool and filesystem to zfsloader, which uses those for loaddev and
> default value of currdev.  A different pool+filesystem could be selected in
> zfsloader for booting kernel.  Also if vfs.root.mountfrom is not explicitly set
> and is not derived from fstab, then it gets set to the selected boot filesystem.
> 
> This should could be used as a foundation for the support of Solaris-like boot
> environment selection.  I believe that other people have already developed
> scripts utilizing ZFS capabilities to provide other aspects of management of
> boot environments.
> 
> I am particularly interested in reviews of my attempt to make ZFS boot support
> arch-independent.  The arches, of course, would have to add some code to make
> use of that support.  Currently I only enabled it for x86.
> 

I can't say much about these patches as a whole as they are rather
big and I'm not aware of all the details of ZFS. However, one bit that
makes the current implementation x86-specific is zfs_dev_init(). If
you could move it to the MD part in the course of these patches that
would be great. If you could also take the second patch in PR 165025
into account, which I plan to commit once the issue with the current
ofw_disk.c are properly solved, that would be great.

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120422212102.GA66855>