> 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. Dave -- 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
