Date: Sun, 2 Jun 2013 12:39:35 -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.1306021156010.9922@wonkity.com> In-Reply-To: <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@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> <alpine.BSF.2.00.1306020834050.8625@wonkity.com> <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@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:46, Warren Block <wblock@wonkity.com> wrote: > 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. Well, yes, but mount it read-only. gnop is (yet another) GEOM transform. It should be non-destructive as long as you don't write to it. > 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? The trick would be figuring out what number was used by the RAID controller. > 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). Yes, it's sectors--the last column is human-readable. But the GEOM logical device might be constructed from the GPT parameters. It may not see the additional blocks on the physical device until the GPT tables are repaired. Which might corrupt the actual data. Really, the easiest way would be to temporarily install the old RAID controller and copy the data off the array. >> 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. gmirror is good. GPT is also good. The combination is a problem. gmirror metadata overwrites the backup GPT, so those disks will show "corrupt" also. For now, the recommended workaround is to just use MBR, which doesn't have any metadata at the end of the disk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1306021156010.9922>