One of the things you could to verify that in fact the RAID array is sane is to run the following command: debugfs -s 32768 -b 4096 /dev/md0 Then you can examine the file system via the debugfs commands "cd", "ls", "cat", "dump" (or even "rdump", although that's more interesting recovery operations). I would suggest looking at a number of directories and make sure they look as you expect them, and that you try dumping out a few files and making sure that they are uncorrecpted. If the majority of the files you look at look sane, then it should be safe to let e2fsck recover the file system from the backup superblock. In the future, we'll be able to use the metadata checksum feature to automate this process (as well as being able to more gracefully and automatically handle inode table blocks written to the wrong location on disk, overwriting other inode table blocks) --- but a bit more testing is needed before I'd recommend it for regular users. (In particular, I want to make sure that random journal corruptions are handled correctly when the metadata checksum feature is enabled --- before we start having more enthusiastic users try out bleeding edge features on production file systems....) Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
