Date: Sun, 2 Jun 2013 17:12:48 +0200 From: Alban Hertroys <haramrae@gmail.com> To: Warren Block <wblock@wonkity.com> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-stable@freebsd.org Subject: Re: Corrupt GPT header on disk from twa array - fixable? Message-ID: <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> In-Reply-To: <alpine.BSF.2.00.1306020834050.8625@wonkity.com> References: <EA2DCEC2-8B07-434B-8B60-8AB15B3788F7@gmail.com> <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <CA%2B7WWSe7O9%2Bxq3UEJ%2B%2BtM1d3tphf7pWU=n4DoQY8XZq39RRScQ@mail.gmail.com> <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> <alpine.BSF.2.00.1306020834050.8625@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 2, 2013, at 16:46, Warren Block <wblock@wonkity.com> wrote: > On Sun, 2 Jun 2013, Alban Hertroys wrote: >=20 >> On Jun 2, 2013, at 16:12, Kimmo Paasiala <kpaasial@gmail.com> 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) >> <ST3500418AS CC34> 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: <ST3500418AS CC34> 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: <Hitachi HDS721010CLA332 JP4OA39C> 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: <WDC WD1002FAEX-00Z3A0 05.01D05> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3659A498-F0EA-4AF3-80EA-40038DCA9CC7>