Date: Sun, 2 Jun 2013 08:46:07 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Alban Hertroys <haramrae@gmail.com> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-stable@freebsd.org Subject: Re: Corrupt GPT header on disk from twa array - fixable? Message-ID: <alpine.BSF.2.00.1306020834050.8625@wonkity.com> In-Reply-To: <2943982C-719E-45D0-9B26-43B725738F83@gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Jun 2013, Alban Hertroys wrote: > On Jun 2, 2013, at 16:12, Kimmo Paasiala <kpaasial@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1306020834050.8625>