On Mon, Nov 19, 2012 at 6:41 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > 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 Sorry Ted, but that is not working. mint mnt # debugfs -s 32768 -b 4096 /dev/md0 debugfs 1.42.5 (29-Jul-2012) /dev/md0: Bad magic number in super-block while opening filesystem debugfs: debugfs: ls ls: Filesystem not open debugfs: -- 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
