Corrupt GPT header on disk from twa array - fixable?

[Alban Hertroys]

On Jun 2, 2013, at 16:46, Warren Block <wblock at wonkity.com> wrote:

> On Sun, 2 Jun 2013, Alban Hertroys wrote:
> 
>> On Jun 2, 2013, at 16:12, Kimmo Paasiala <kpaasial at gmail.com> wrote:
>>> 
>>> 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?
>> 
>> From dmesg:
>> 
>> 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=2, 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.
> 
> There is a lot of stuff going on there.
> 
> 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.
> 
> 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.