On Sun, 2 Jun 2013, Alban Hertroys wrote:
On Jun 2, 2013, at 16:12, Kimmo Paasiala <kpaas...@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.
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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
