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