From owner-freebsd-stable@FreeBSD.ORG Sun Jun 2 15:12:52 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 071B7800 for ; Sun, 2 Jun 2013 15:12:52 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 91BF01D65 for ; Sun, 2 Jun 2013 15:12:51 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id w58so1019792wes.27 for ; Sun, 02 Jun 2013 08:12:50 -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=yOZyN+jOEm+NNGePt8QHciqSgbayRLljv0ixLOhRYVM=; b=JhY2RhCA57sjMBWKPWJTTh7nEYbKvbBEnq6bJ/go2Pyow74YCBtyGg42N6s9+nWxtK 8c1RsLPY3AdgjA2U+I5nIiNvKKEoRhhmL9tSv1ejZ5GT8xxxtLIM3umq90+1GTwBqNiO UbKZnRx6plhpnmRs9fLaygS9e3+dilxWbRvucZi8S+JNsriWVj/53SyI6nTAvXH7J6qM K/fpydwqCc73SGFfRGSYLTq0J9Kcd5iVSsQO7s37++D0mK5v+5ZK6m2QlMhQIGQUl/Tx 8zxKUhtWwc1oiiHgb3mrEF9qx1diSLYgLXWYvbOBDcybMaBDYgBICIRO4cPZRZTtixeY Igbg== X-Received: by 10.180.108.3 with SMTP id hg3mr9515113wib.17.1370185970719; Sun, 02 Jun 2013 08:12:50 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id ff10sm17132786wib.10.2013.06.02.08.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 08:12:49 -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: Sun, 2 Jun 2013 17:12:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> References: <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <2943982C-719E-45D0-9B26-43B725738F83@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 15:12:52 -0000 On Jun 2, 2013, at 16:46, Warren Block wrote: > On Sun, 2 Jun 2013, Alban Hertroys wrote: >=20 >> On Jun 2, 2013, at 16:12, Kimmo Paasiala wrote: >>>=20 >>> Looking at the gpart(8) output it seems that only 20GBs of the disk = is >>> recognized by the disk driver but the GPT table still shows the full >>> capacity 910GB. I'd say that the GPT table is in fact correct and if >>> you can somehow get the disks to be recognized with full capacity = they >>> should be usable as they are. What does dmesg(8) say about the = disks? >>=20 >> =46rom dmesg: >>=20 >> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >> ada2: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, = ignored) >> ATA-8 SATA 2.x device >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR >> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada2: Command Queueing enabled >> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada2: Previously was known as ad8 >> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> ada3: ATA-8 SATA 2.x device >> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada3: Command Queueing enabled >> ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada3: Previously was known as ad10 >> ada4 at ahcich4 bus 0 scbus4 target 0 lun 0 >> ada4: ATA-8 SATA 2.x device >> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_IOERROR, ignored) >> ada4: 300.000MB/s transfers (SATA 2.x, usbd_setup_device_desc: = getting device descriptor at addr 2 failed, USB_ERR_IOERROR >> UDMA6, PIO 8192bytes) >> ada4: Command Queueing enabled >> ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada4: Previously was known as ad12 >> ada5 at ahcich5 bus 0 scbus5 target 0 lun 0 >> ada5: ATA-8 SATA 3.x device >> ada5: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada5: Command Queueing enabled >> ada5: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada5: Previously was known as ad14 >> SMP: AP CPU #1 Launched! >> Timecounter "TSC-low" frequency 13371081 Hz quality 800 >> GEOM: ada2: the secondary GPT header is not in the last LBA. >> GEOM: ada3: the secondary GPT header is not in the last LBA. >> GEOM_MIRROR: Device mirror/boot launched (2/2). >> GEOM_MIRROR: Device mirror/swap launched (2/2). >> GEOM_MIRROR: Device mirror/root launched (2/2). >> GEOM: ada4: the secondary GPT header is not in the last LBA. >> GEOM: ada5: the secondary GPT header is not in the last LBA. >=20 > There is a lot of stuff going on there. >=20 > You switched from a hardware RAID card to something else in the new = machine. Maybe a different card, or maybe just the motherboard. The = old controller may have put metadata on the drives and hidden it. On a = new controller, that metadata is not hidden. This would explain the = "secondary GPT header is not in the last LBA" message. >=20 > If the old controller "split" the combined drives into virtual = volumes, there may be another GPT somewhere in the remainder of the = drive. If you could find that, gnop(8) could be used with an offset to = mount it. This could be another explanation for the GPT being "corrupt": = the GPT at the start of the drive is for the first volume, the backup = GPT at the end of the drive is for the second volume. It did indeed! I just sent a message about that, as I realised that = wasn't clear from my original description. I think gnop(8) is the answer = to my question. 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. 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? 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). > 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. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest.