MFC of ZFSv15

[Dan Mack]

Thanks for the confirmation.  This worked fine and I did notice that "zpool upgrade zroot" was nice enough to emit the reminder:

  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

which is slightly different than the recipe given in /usr/src/UPDATING:

        "gpart bootcode -p /boot/gptzfsboot -i 1 ad0"

Since the recipe for my root/zfs system included pmbr and gptzfsboot, I used the example emitted from the zpool command instead of the one from UPDATING.


e.g.

  pool: zroot
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
	still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
	pool will no longer be accessible on older software versions.
 scrub: none requested
config:

	NAME           STATE     READ WRITE CKSUM
	zroot          ONLINE       0     0     0
	  mirror       ONLINE       0     0     0
	    gpt/disk0  ONLINE       0     0     0
	    gpt/disk1  ONLINE       0     0     0

errors: No known data errors

(zfs) ~ # zpool upgrade zroot
This system is currently running ZFS pool version 15.

Successfully upgraded 'zroot' from version 14 to version 15

If you boot from pool 'zroot', don't forget to update boot code.
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

	gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4
ad4 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad5
ad5 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad6
ad6 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad7
ad7 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad8
ad8 has bootcode

(zfs) ~/zfs # reboot



Dan

On Sep 19, 2010, at 12:41 PM, Matthew Seaman wrote:

> On 19/09/2010 17:36:01, Dan Mack wrote:
>> But I should be able to boot my ZFSv14 root pool using the ZFSv15
>> build of FreeBSD, correct?   But the problem scenario would be when
>> I've upgraded my root pool to v15 and I attempt to boot it with v14
>> boot loader.  At least that is what I think ...
> 
> Yes.  The bootloader is not prescient, so  bootloader compiled against
> v14 can't cope with a zpool using v15.  It's only the on-disk format
> that counts in this: zfs software will operate perfectly well with older
> on-disk data formats.
> 
>> I guess what I'm getting at is ... you should be able to buildworld,
>> installkernel, reboot, installworld, reboot without worry.   But
>> after your run 'zpool upgrade', you will need to re-write the
>> bootcode using gpart on each of your root pool ZFS disks.
> 
> If you want to be completely paranoid, you could update the bootcode on
> your boot drive (or one out of a mirror pair, if that's what you're
> using) at the point of running installkernel and way before you run
> 'zpool upgrade'.  In theory, should this go horribly wrong and you end
> up with an unbootable system, you can recover by booting the 8.0 install
> media into FIXIT mode and reinstalling the bootblocks from there (or
> booting from the other disk in your mirror set).  Once you've got a
> system you know will reboot with the new bootblocks, then go ahead and
> with installworld and updating the zpool version.
> 
>> Am I understanding this correctly ?
> 
> Yep.  That's quite right.  Running 'zpool upgrade -a' is one of those
> operations you can't easily reverse, so designing an upgrade plan where
> you can stop and back-out at any point is quite tricky.  Fortunately,
> the risk of things going wrong at the point of running zpool upgrade is
> really very small, so for most purposes, just ploughing ahead and
> accepting the really very small risk is going to be acceptable.
> 
> 	Cheers,
> 
> 	Matthew
> 
> -- 
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                  Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
> JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW
> 

Dan
--
Dan Mack
mack at macktronics.com