[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121119184107.GA29487@thunk.org>
Date: Mon, 19 Nov 2012 13:41:07 -0500
From: Theodore Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Drew Reusser <dreusser@...il.com>,
George Spelvin <linux@...izon.com>, linux-ext4@...r.kernel.org
Subject: Re: Issue with bad file system
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists