From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 20:12:17 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FBCF106564A for ; Sun, 12 Feb 2012 20:12:17 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id B60A08FC08 for ; Sun, 12 Feb 2012 20:12:16 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.4/8.14.4) with ESMTP id q1CKCGZu056555; Sun, 12 Feb 2012 15:12:16 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.1 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.4/8.14.4/Submit) id q1CKCGNQ056554; Sun, 12 Feb 2012 15:12:16 -0500 (EST) (envelope-from lidl) Date: Sun, 12 Feb 2012 15:12:16 -0500 From: Kurt Lidl To: Gavin Mu Message-ID: <20120212201216.GA56121@pix.net> References: <201202121530.q1CFU8fH047653@freefall.freebsd.org> <20120212192552.GA55852@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120212192552.GA55852@pix.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:12:17 -0000 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 partitioning. 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. -Kurt