Hi Dave, On 09/28/2013 11:47 AM, Dave Gomboc wrote: >> fsck.ext3 -n /dev/mapper/teramooch-srv >> e2fsck 1.42.7 (21-Jan-2013) >> ext2fs_open2: Bad magic number in super-block >> fsck.ext3: Superblock invalid, trying backup blocks... >> fsck.ext3: Bad magic number in super-block while trying to open >> /dev/mapper/teramooch-srv > > So, I am now restoring the content of the two drives that I altered > (by running ddrescue again) , so that I have all four drives copied as > before. > > If each pair of two drives genuinely have the same information on > them, then I only seem to have that one method of array assembly > available to me, in which case I suppose I will need to try to scan at > a lower level, searching for parts of the ext3 filesystem of the > logical volume that I cannot mount. I could certainly use some advice > on what might be worth trying in this scenario. Even if I can't get > everything back, I should try to get anything back that I can. > > However, if there is some variation between what two drives that > report place '0' (or the two drives that report place '3') are > actually holding, then I have more array assembly options to try > before dealing with the above issue. > > Is there already some software out there (or do you think it would not > be particularly difficult for an experienced software developer who > does not have extensive knowledge of linux internals -- such as myself > :-) that could be used to treat the physical drives as read-only, and > do any "writes" to them to a layer in RAM instead? That is, it would > read from RAM first, then from the disk only if nothing was present in > RAM, and always leave the contents of the disks unchanged when writing > back to RAM (never writing through to disk)? If I had something like > that, I could make various attempts, then discard the changes easily > after failed tries, without having to restore the hard drive contents > from the actual original drive afterwards Of course, I don't have > several terabytes of RAM, but I think there is really only a small > portion of the disk that is being edited when I am doing various > operations such as mdadm --assemble and vgchange. I've never had to do this, but I would use the device mapper "snapshot" target device. You could use it with a ram device, but I'd use another partition in persistent mode. That way, once you succeed, you can merge the result back into the real devices. Start with the device mapper documentation in the kernel tree. Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
