On Jun 2, 2013, at 16:46, Warren Block <wbl...@wonkity.com> wrote: > 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.
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. _______________________________________________ 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"
