From owner-freebsd-geom@FreeBSD.ORG Tue Aug 14 04:45:16 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32FB16A417 for ; Tue, 14 Aug 2007 04:45:16 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5459813C428 for ; Tue, 14 Aug 2007 04:45:16 +0000 (UTC) (envelope-from hg@queue.to) Received: (qmail 51728 invoked from network); 14 Aug 2007 00:45:15 -0400 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 14 Aug 2007 00:45:15 -0400 Message-ID: <46C1335A.2000008@queue.to> Date: Tue, 14 Aug 2007 00:45:14 -0400 From: Howard Goldstein User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: Ulf Lilleengen , cyberleo@cyberleo.net References: <46BE65EC.1050906@queue.to> <46BE79AE.2070007@cyberleo.net> <20070813091406.GA3078@stud.ntnu.no> In-Reply-To: <20070813091406.GA3078@stud.ntnu.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: RESOLVED - Re: graid5 or gvinums - bootable? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 04:45:17 -0000 Ulf Lilleengen wrote: > On Sat, Aug 11, 2007 at 10:08:07PM -0500, CyberLeo Kitsana wrote: >> Howard Goldstein wrote: >>> Q: Should a graid5 or gvinum provider be expected to be bootable, >>> assuming the prover's partition table has an active bootable partition >>> containing a properly bsdlabeled 'a' slice with the /boot subdirectories >>> in it (i.e., all of the stuff you normally need in an ordinary, non-geom >>> system to have a bootable slice)? >>> >>> Teh googling is somewhat helpful indicating that the boot loader can now >>> deal with the GEOM'd gvinum as the boot device, and of course it works >>> with gmirror but that's not really surprising since that provider >>> wouldn't doesn't have its /boot slice striped into ribbons across >>> multiple consumers like graid5 and gvinum in raid-5. >> I haven't tried with just /boot, but I have a machine with a 1.5GB >> mirror across four disks for the root filesystem, with a graid5 across >> the remaining space for the other filesystems. That works just fine. >> >> As far as I know, however, no boot loader can understand >> software-striped or software-raid5ed filesystems, given that it would >> essentially need to implement the relevant geom providers itself. >> > Yes. This is no problem with mirrors, since it's essentially just to read the > first sectors of it. However, the other reason is that gmirror stores it's > metadata at the end, so the loader won't have to care about it. So, booting of a > gvinum volume will not work, but using another partition for /boot, and gvinum for > root should work. What I eventually did here across three identical 320gb drives was to set up three slices on all of the drives s1 gmirror for / s2 gstripe for swap and /tmp s3 graid5 for /var and /usr I ran into a problem though, the geometry of the onboard ICH5 RAID controlling two of the drives turned out to be different than the 3ware Escalade's geometry for the same drive. This seems to have caused the 3ware controller to do unaligned i/o with a performance hit I didn't notice until it also caused intermittent warnings for the 3ware driver when its malloc failed. Setting up the stripes so they all began on cylinder boundaries for both geometries appears to have worked (at least it's initializing the graid5 array about twice as fast as when it was unaligned) I wonder if I could have avoided a lot of annoying arithmetic with looooong integers if I set the consumers up on the partitions in a single but it seemed a bridge too far Thanks Cyberleo and Ulf for your observations and comments