From owner-freebsd-stable@FreeBSD.ORG Sun Jun 2 22:38:59 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 A245B6B7 for ; Sun, 2 Jun 2013 22:38:59 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 37AAD1B7F for ; Sun, 2 Jun 2013 22:38:59 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x55so1178302wes.4 for ; Sun, 02 Jun 2013 15:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fLza5fY/4kJZL5MgM/sh9hiHvrSDUcci5XAPw/Q36h0=; b=r6MHeHzT/ueieJ1F9UZoWh11SLwdzhOr0mNifuzUtFEoMf7VNjlt8a8V1pm1VIZuoj WoDdNa8tLVMrcXZwsg9JrpW+Q2KdWolZBcGlkYp42WfapQ1iJm7McuNScakFNfHboC14 Is/+8ZMNQFRc9p8H3svO6kFBNGRylesipFJSriCurcpsgafejzt5VLMSS3XXTIywbyVa ZExI4KCWuvqvLid+X4/LmGThWsRVxHuIsNTJpzpYSADgoSF5lMNrmRONFTICTJ5ojXRw VlA4upADuBF0s6y30Gh8XY/HwZpyK+reJFiux3sp+OAkw4ZaoRHllG6bm0z4sSQRpYLF //Hw== X-Received: by 10.180.206.135 with SMTP id lo7mr10134983wic.64.1370212738346; Sun, 02 Jun 2013 15:38:58 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id fv11sm19581321wic.11.2013.06.02.15.38.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 15:38:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Corrupt GPT header on disk from twa array - fixable? From: Alban Hertroys In-Reply-To: Date: Mon, 3 Jun 2013 00:38:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> To: Warren Block X-Mailer: Apple Mail (2.1503) 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 22:38:59 -0000 On Jun 2, 2013, at 20:39, Warren Block wrote: > 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?: >>=20 >> # kldload geom_nop >> # gnop create -v -o 41943006 -S 512 ada4 >> # mount /dev/ada4.nop /mnt >>=20 >> I get the impression that gnop might be non-destructive, but that's = not entirely clear from the man page. >=20 > 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. Yup, writing to them obviously could be destructive. I was aware of = that, but I hadn't thought of mounting them read-only. Thanks. >> I tried the above on ada5 (the other half of the mirror that I = applied gpart recover to earlier), but it spews: >>=20 >> gnop: Invalid offset for provider ada5. >>=20 >> What number does it expect for that offset? >=20 > The trick would be figuring out what number was used by the RAID = controller. Ah right, I need the start of the next volume. I think my calculation = put me at the start of the RAID controllers volume header block for the = first volume - a few sectors too early probably. I suppose it shouldn't take too long finding the start of the second = volume with some trial and error now that I know to look past sector = 41943005 + 1 + volume header size. I'll have a look whether perhaps the = controllers' documentation mentions anything of a size... >=20 >> 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). >=20 > 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. >=20 > Really, the easiest way would be to temporarily install the old RAID = controller and copy the data off the array. Well, that would mean I'd have to assemble the old server again, as the = controller is not compatible with the hardware in the new one. And that = would probably be unnecessary as well, since I already did copy the data = off those disks. I was just curious whether it would be possible to read that data off = the disks while I still have them (with their original contents) in the = new server in the eventuality that I _did_ forget to copy something over = or that something wasn't copied over correctly. I copied the data over a 100MBit ethernet link, which was the fastest = option I had with the old server; it had USB1 and no native SATA. Hence = the RAID controller, but that was on a now deprecated PCI-X channel = (those 64-bit parallel things) and all 4 ports were in use. Not to mention that the CPU was so old that it had a rather narrow = margin for operating temperatures and overheated several times during = the copying process, because rsync+sshd put a relatively high load on = the CPU (An old Athlon XP 2000+). If I manage to get those volumes mounted with gnop, that would give me = the opportunity to checksum the contents of the original disks with the = copied content on the new disks. I'm sure that rsync is quite reliable, but I had a few hangs of the old = server during the process and although rsync is capable of continueing = where it left off, it'd be nice to be able to verify that worked as = advertised. I'll experiment some more with gnop, but if that doesn't get me anywhere = I'll probably just wipe those old disks with a new GPT partition table = so that I can use them for storage again. There shouldn't be anything on = it that I don't have already. > 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. Or you mirror the partitions on the disk as Jeremy pointed out, in which = case the backup GPT goes to the end of the disk, while the gmirror = meta-data goes to the end of each partition within that space. I get = that now. Thanks for all the help, guys! If I figure out how to access those extra volumes, I'll report back. Who = knows who'll run into the same problem some day (possibly less prepared = for the situation). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest.