sparc64/165025: [PATCH] zfsboot support for sparc64

Kurt Lidl lidl at
Sun Feb 12 20:12:17 UTC 2012

One other thing that I would like to mention about ZFS booting,
since I did a bunch of investigative work on this a while ago.
(This is part of the reason I'm so happy to see the code to
actually implement this for the sparc64 platform.)

On a x86 machine, with GPT partitioning, the current "best practices"
for ZFS works out to use the following setup:
	partition 0: type freebsd-boot (sized ~64k, aligned 4K block)
	partition 1: type freebsd-swap (sized however, aligned 4K block)
	partition 2: type freebsd-zfs (sized however, aligned 4k block)

The need for the freebsd-swap partition is due to the lack of crash-dump
support into zvols, as I recall. 

There's no reason a similar setup couldn't work on sparc64 hardware,
just substituting vtoc8 style partitioning instead of GPT style

The only real complication that I know is that the vtoc8 partitions
are sized on "cylinder" boundaries. So when you gmirror two partitions
together, and gmirror re-writes the size of the partition, to shave
off 64K from the end of the partition, you get error messages like
this from the system:

	GEOM: mirror/groot: invalid VTOC8 label.
	GEOM: ufsid/4f24cf7f3350aae5: invalid VTOC8 label.

(In this case, I have ufs boot partition, that is gmirrored with a
second disk.  I also have a dedicated swap partition, that is also
gmirrored onto a second disk.)

If the zfs boot code was made to search for a freebsd-zfs type of
partition in the vtoc8 table, there's no reason that one couldn't
have the following vtoc8 partition table:

partition 1: type freebsd-boot
	starting at cylinder 0, sized 1 cylinder, contents zfsboot1
partition 2: type freebsd-swap
	starting at cylinder 2, sized however large, contents swap/crash space
partition 3: entire disk
partition 4: type freebsd-zfs
	starting at some cylinder boundary, directly after swap partition

This ignores the 3.5MB boot space at the front of the zpool, but until
one can crash-dump onto a zvol, I don't know that one can really do
much better.


More information about the freebsd-sparc64 mailing list