From owner-freebsd-stable@FreeBSD.ORG Sun Jun 2 18:39:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 42CAF18C for ; Sun, 2 Jun 2013 18:39:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id DDE9B138C for ; Sun, 2 Jun 2013 18:39:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r52IdZpp010131; Sun, 2 Jun 2013 12:39:35 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r52IdZpL010128; Sun, 2 Jun 2013 12:39:35 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 2 Jun 2013 12:39:35 -0600 (MDT) From: Warren Block To: Alban Hertroys Subject: Re: Corrupt GPT header on disk from twa array - fixable? In-Reply-To: <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> Message-ID: References: <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 02 Jun 2013 12:39:36 -0600 (MDT) Cc: Kimmo Paasiala , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 18:39:37 -0000 On Sun, 2 Jun 2013, Alban Hertroys wrote: > On Jun 2, 2013, at 16:46, Warren Block wrote: > I've never worked with gnop before; is this a safe approach?: > > # kldload geom_nop > # gnop create -v -o 41943006 -S 512 ada4 > # mount /dev/ada4.nop /mnt > > I get the impression that gnop might be non-destructive, but that's not entirely clear from the man page. Well, yes, but mount it read-only. gnop is (yet another) GEOM transform. It should be non-destructive as long as you don't write to it. > I tried the above on ada5 (the other half of the mirror that I applied gpart recover to earlier), but it spews: > > gnop: Invalid offset for provider ada5. > > What number does it expect for that offset? The trick would be figuring out what number was used by the RAID controller. > And what exactly is gpart show showing? I was under the assumption > that both would be sectors (which judging from the numbers would be > 512 bytes in size). Yes, it's sectors--the last column is human-readable. But the GEOM logical device might be constructed from the GPT parameters. It may not see the additional blocks on the physical device until the GPT tables are repaired. Which might corrupt the actual data. Really, the easiest way would be to temporarily install the old RAID controller and copy the data off the array. >> Finally, GPT and gmirror are combined. That's a problematic >> combination because both want metadata in the last block of the >> drive. The new section in the Handbook about RAID1 (gmirror) >> describes that in the "Metadata Issues" section: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/GEOM-mirror.html > > I'm pretty sure the disks on the controller had nothing to do with gmirror ever. > > Gmirror is only applied to a pair of new disks that I put in the (new) > server to be able to copy my data over. I hadn't expected to be able > to rely on those original disks to be readable at all without the > controller, so I needed some place to store the data. I like the > redundancy of a mirror, so I used gmirror for (only) the new disks. gmirror is good. GPT is also good. The combination is a problem. gmirror metadata overwrites the backup GPT, so those disks will show "corrupt" also. For now, the recommended workaround is to just use MBR, which doesn't have any metadata at the end of the disk.