[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: another seriously corrupt ext3 -- pesky journal



On Tue, Aug 19, 2003 at 01:27:43PM -0400, Erez Zadok wrote:
> As a quick reminder: I had run "mke2fs -S" on a copy of this corrupt f/s,
> specifically wiping the journal file, superblocks, and group descriptors.
> Then ran fsck for hours.  It found tons of errors, and only recovered a
> small portion of data.  I don't know how much that data loss was exacerbated
> (if any), but the -S flag.

I doubt it was exacerbated by the lack of the -S flag.

> Alas, I cannot open the f/s for read/write, and catastrophic mode won't help
> me in its current form.  So I'm in need of your proposed mods to debugfs.
> Could you get me a modified version, patches to one, or just point me at
> where in the source could I try to hack this myself?
> 
> BTW, the debugfs error message is not terribly useful or descriptive.  What
> does it _really_ mean?
> 
> In the mean time, I've hacked a version of debugfs (from 1.34) and commented
> out the check for the -c and -w options, allowing read/write with -c.  This
> is what happened:

The patches to debugfs is to remove the read/write check to -c, and
then auditing all of debugfs's code paths to make sure that the
bitmaps are not initialized (for in catastrophic mode the bitmaps are
not read in if they are buggy), that debugfs won't crash or do
something evil when in read/write mode.  So your hack is the first
part of the patch.  I haven't had a chance to do the audit of debugfs
to make sure making that change is safe, though.  (It _probably_
wouldn't cause any data loss, but some of debugfs's read/write
commands might core dump).

> I don't understand why after turning off the has_journal bit, I'm still
> getting errors related to the journal.
> 
> My guess is that e2fsck checks for the journal inode no matter what, so I
> need to unlink it.  So next I tried more desperate measures:

Yup, e2fsck checks to see if the standard journal inode is there.  

> ------------------------------------------------------------------------------
> # ~/e2fsprogs-1.34/debugfs/debugfs -c -w -b 4096 -s 20480000 /dev/loop1
> debugfs 1.34 (25-Jul-2003)
> /dev/loop1: catastrophic mode - not reading inode or group bitmaps
> debugfs:  stat <8>
> stat: Invalid argument while reading inode 8
> debugfs:  features
> Filesystem features: filetype sparse_super large_file
> debugfs:  clri <8>
> clri: Invalid argument while reading inode 8
> debugfs:  freei <8>
> freei: Filesystem bitmaps not loaded
> debugfs:  quit
> 
> # e2fsck -n -B 4096 -b 20480000 /dev/loop1
> e2fsck 1.32 (09-Nov-2002)
> e2fsck: Invalid argument while checking ext3 journal for /dev/loop1
> ------------------------------------------------------------------------------

I'll have to take a look at the output of dumpe2fs, but if clri
failed, that probably means that block group descriptors that tell us
where to find the first part of the inode table was corrupted.  (This
is one of the things which mke2fs -S fixes).

						- Ted




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]