Date: Mon, 3 Jun 2013 00:38:56 +0200 From: Alban Hertroys <haramrae@gmail.com> To: Warren Block <wblock@wonkity.com> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-stable@freebsd.org Subject: Re: Corrupt GPT header on disk from twa array - fixable? Message-ID: <EEDDED25-364C-4637-AAE5-F215D41A2D6C@gmail.com> In-Reply-To: <alpine.BSF.2.00.1306021156010.9922@wonkity.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> <alpine.BSF.2.00.1306021156010.9922@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 2, 2013, at 20:39, Warren Block <wblock@wonkity.com> wrote: > 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?: >>=20 >> # kldload geom_nop >> # gnop create -v -o 41943006 -S 512 ada4 >> # mount /dev/ada4.nop /mnt >>=20 >> I get the impression that gnop might be non-destructive, but that's = not entirely clear from the man page. >=20 > 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. Yup, writing to them obviously could be destructive. I was aware of = that, but I hadn't thought of mounting them read-only. Thanks. >> I tried the above on ada5 (the other half of the mirror that I = applied gpart recover to earlier), but it spews: >>=20 >> gnop: Invalid offset for provider ada5. >>=20 >> What number does it expect for that offset? >=20 > The trick would be figuring out what number was used by the RAID = controller. Ah right, I need the start of the next volume. I think my calculation = put me at the start of the RAID controllers volume header block for the = first volume - a few sectors too early probably. I suppose it shouldn't take too long finding the start of the second = volume with some trial and error now that I know to look past sector = 41943005 + 1 + volume header size. I'll have a look whether perhaps the = controllers' documentation mentions anything of a size... >=20 >> 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). >=20 > 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. >=20 > Really, the easiest way would be to temporarily install the old RAID = controller and copy the data off the array. Well, that would mean I'd have to assemble the old server again, as the = controller is not compatible with the hardware in the new one. And that = would probably be unnecessary as well, since I already did copy the data = off those disks. I was just curious whether it would be possible to read that data off = the disks while I still have them (with their original contents) in the = new server in the eventuality that I _did_ forget to copy something over = or that something wasn't copied over correctly. I copied the data over a 100MBit ethernet link, which was the fastest = option I had with the old server; it had USB1 and no native SATA. Hence = the RAID controller, but that was on a now deprecated PCI-X channel = (those 64-bit parallel things) and all 4 ports were in use. Not to mention that the CPU was so old that it had a rather narrow = margin for operating temperatures and overheated several times during = the copying process, because rsync+sshd put a relatively high load on = the CPU (An old Athlon XP 2000+). If I manage to get those volumes mounted with gnop, that would give me = the opportunity to checksum the contents of the original disks with the = copied content on the new disks. I'm sure that rsync is quite reliable, but I had a few hangs of the old = server during the process and although rsync is capable of continueing = where it left off, it'd be nice to be able to verify that worked as = advertised. I'll experiment some more with gnop, but if that doesn't get me anywhere = I'll probably just wipe those old disks with a new GPT partition table = so that I can use them for storage again. There shouldn't be anything on = it that I don't have already. > 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. Or you mirror the partitions on the disk as Jeremy pointed out, in which = case the backup GPT goes to the end of the disk, while the gmirror = meta-data goes to the end of each partition within that space. I get = that now. Thanks for all the help, guys! If I figure out how to access those extra volumes, I'll report back. Who = knows who'll run into the same problem some day (possibly less prepared = for the situation). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EEDDED25-364C-4637-AAE5-F215D41A2D6C>