From owner-freebsd-geom@FreeBSD.ORG Thu Mar 10 01:50:14 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E97416A4CE; Thu, 10 Mar 2005 01:50:14 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF4F43D3F; Thu, 10 Mar 2005 01:50:13 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-89-235.roa.east.verizon.net [151.199.89.235]) by gromit.dlib.vt.edu (8.13.1/8.13.1) with ESMTP id j2A1o8K1073102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2005 20:50:09 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j2A1o3OY086615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2005 20:50:03 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j2A1o28w086614; Wed, 9 Mar 2005 20:50:02 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: "Loren M. Lang" In-Reply-To: <20050309232448.GA28861@alzatex.com> References: <200503091503.33431.michael.riexinger@de.clara.net> <20050309202225.GP9291@darkness.comp.waw.pl> <1110408229.690.8.camel@zappa.Chelsea-Ct.Org> <20050309232448.GA28861@alzatex.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 09 Mar 2005 20:50:01 -0500 Message-Id: <1110419401.690.27.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port cc: Michael Riexinger cc: Pawel Jakub Dawidek cc: freebsd-geom@freebsd.org Subject: Re: gmirror metadata X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 01:50:14 -0000 On Wed, 2005-03-09 at 15:24 -0800, Loren M. Lang wrote: > On Wed, Mar 09, 2005 at 05:43:49PM -0500, Paul Mather wrote: > > On Wed, 2005-03-09 at 21:22 +0100, Pawel Jakub Dawidek wrote: > > > On Wed, Mar 09, 2005 at 03:03:33PM +0100, Michael Riexinger wrote: > > > +> Hi, > > > +> > > > +> i have a hp dl320 with an integrated raid controller. I don't want to > > > +> use that, instead i want to use gmirror. To use the 2 IDE drives, I > > > +> configured 2 raid0 arrays (each with 1 drive) in the controller's bios. > > > +> Now i wanted to use gmirror, labeled the second drive. When I did a > > > +> reboot, the raid controller's bios seems to overwrite the gmirror > > > +> metadata with its own metadata. Is it impossible to use gmirror witch > > > +> such a configuration? > > > > > > I'll be very odd if controller's BIOS overwrite disk data. > > > > Actually, I had the same type of thing happen to me. I put a LSI > > MegaRAID IDE 100 that was lying around into my system and attached my > > existing geom_mirrored drives to it. I didn't want to use the drives as > > an ATA RAID, and never set them up as that in the RAID BIOS. I simply > > wanted to upgrade from my onboard ATA 33 to the ATA 100 speed the card > > supported, to get faster disk I/O. > > > > To my surprise and regret, my system wouldn't boot properly (couldn't > > locate the root filesystem) because the ATA RAID card had spammed its > > metadata over the geom_mirror metadata, and my drives were no longer > > detected as a geom_mirror. > > > > I believe one difference between this and Micheal's situation is that, > as I understand it, you created the mirror with a normal ide controller, > then attached it to the raid controller after that, where Micheal > labelled it while it was under the raid controller. A raid controller > might reserve a sector or track for it's own meta-data, but it should > still provide a slightly smaller disk that would be completely > transparent. You couldn't see the raid controller's meta-data sectors > nor would any sectors you see or write to be modified by the raid > controller. I would agree with this if you could only see the disks through the RAID controller (as I understand the case to be with, e.g., the twe, twa, amr, etc., controllers), but lots of these built-in cheapo (read "software") ATA RAID controllers also expose the underlying disks. (In ATA RAID terms, you'd see ar? and ad? devices.) I'd expect the ar? device to hide the RAID metadata, but not the ad? devices. If you label the ad? devices when creating your geom_mirror, this could cause confusion/corruption as far as the ATA RAID BIOS is concerned (because you're bypassing the RAID layer). In my case, I was reacting to Pawel's observation that it would be very odd for a RAID controller's BIOS to overwrite data. I agree with him, or at least in my case I thought it was very rude of the RAID BIOS to spam my disks when I never even entered the RAID BIOS to configure them. (I'd understand if I had---at least then I would have been instructing the BIOS to spam my disks with its metadata!:) But, then again, nothing shocks me regarding these awful LSI MegaRAID IDE 100 cards... :-) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa