sparc64/165025: [PATCH] zfsboot support for sparc64

[Marius Strobl]

The following reply was made to PR sparc64/165025; it has been noted by GNATS.

From: Marius Strobl <marius at alchemy.franken.de>
To: Gavin Mu <gavin.mu at gmail.com>
Cc: bug-followup at freebsd.org, Kurt Lidl <lidl at pix.net>
Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64
Date: Sun, 4 Mar 2012 19:06:52 +0100

 On Mon, Feb 27, 2012 at 10:46:22PM +0800, Gavin Mu wrote:
 > Here is the updated patch to support zfs boot fully. Now boot from
 > mirror/raidz pool are also supported.
 > 
 > zfsboot is the enhancement of boot1. Instead of reading "/boot/loader"
 > from UFS filesystem, it loads the ELF "zfsloader" program from the
 > 3.5MB Boot Block of zpool in current vtoc8 partition (slice).
 > 
 > zfsloader tries to probe the zpool in current vtoc8 partition and if
 > it is valid, it records the guid, then search all disks to find all
 > zpools in the vtoc8 partitions with freebsd-zfs tag. zfsloader uses
 > devalias "disk<n>" to find the disks, so devalias must be defined for
 > all your bootable disks by OBP (aka. {ok} mode). then it boots from
 > the zpool with the same guid.
 > 
 > If you use the whole disk as zpool, you can allocate all disk space
 > into the first vtoc8 partition (for example, ada0a in FreeBSD) tag
 > with freebsd-zfs to create zpool. It is same with creating zpool on
 > the whole disk (ada0).
 > 
 > For reading from multiple disks, some ofw code are changed. The former
 > code does not work when reading from multiple disks and I am not sure
 > if it is possible and how to do this. (I googled but did not find more
 > useful things). So I changed the code to close the current disk before
 > a new disk is opened, and there will be only one disk opened
 > simultaneously. I am not sure if this will slow the disk reading for
 > booting from raidz pool. (It is several minutes slow on my V100
 > machine to boot from raidz zpool).
 
 Typically, opening and closing devices via OFW causes quite a delay,
 the exact impact depends on the firmware version and the devices
 involved though. Therefore, it would be advisable to keep using the
 current approach of caching opened packages. In what way does this
 fail with ZFS? Basically, IEEE 1275 just says that support for
 opening a package more than once depends on the particular package
 but nothing about concurrently opening different packages. Not
 being able to concurrently open different packages also doesn't
 make all that much of a sense as opening one package also means
 to subsequentially open all the parents up to the root if not
 already opened and I think to actually have tested opening disks
 concurrently when writing the current code. Could this fail due
 to one device actually being opened twice, once via the full path
 and once via its alias?
 
 Marius