From owner-freebsd-stable@FreeBSD.ORG Sun Jun 2 14:46:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66A7CBD5 for ; Sun, 2 Jun 2013 14:46:09 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1D59A1C89 for ; Sun, 2 Jun 2013 14:46:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r52Ek75n009106; Sun, 2 Jun 2013 08:46:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r52Ek7qe009103; Sun, 2 Jun 2013 08:46:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 2 Jun 2013 08:46:07 -0600 (MDT) From: Warren Block To: Alban Hertroys Subject: Re: Corrupt GPT header on disk from twa array - fixable? In-Reply-To: <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> Message-ID: References: <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 02 Jun 2013 08:46:08 -0600 (MDT) Cc: Kimmo Paasiala , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 14:46:09 -0000 On Sun, 2 Jun 2013, Alban Hertroys wrote: > On Jun 2, 2013, at 16:12, Kimmo Paasiala 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) > 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: 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: 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: 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