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

Re: another seriously corrupt ext3 -- pesky journal



In message <20030818181354 GC10270 think>, "Theodore Ts'o" writes:
> On Mon, Aug 18, 2003 at 12:39:46PM -0400, Erez Zadok wrote:
[...]
> > Now I was able to start "e2fsck -b 71663616 -B 4096 /dev/md0".  It's been
> > running for a couple of hours already.  Of course, it's discovering all
> > sorts of wonderful new events and spewing messages I've never even seen
> > before. 1/2 a :-)

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.

[...]
> You can use debugfs's feature command to turn off the has_journal bit
> as follows:
> 
> debugfs -w /dev/hdaXX
> debugfs: features ^has_journal
> debugfs: features ^needs_recovery 
> debugfs: quit

Ted, I tried it:

------------------------------------------------------------------------------
# debugfs -w /dev/loop1
debugfs 1.32 (09-Nov-2002)
/dev/loop1: Can't read an inode bitmap while reading inode bitmap
debugfs:  features ^has_journal
features: Filesystem not open
debugfs:  quit
------------------------------------------------------------------------------

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:

------------------------------------------------------------------------------
# ~/e2fsprogs-1.34/debugfs/debugfs -c -w /dev/loop1
debugfs 1.34 (25-Jul-2003)
/dev/loop1: catastrophic mode - not reading inode or group bitmaps
debugfs:  features ^has_journal
Filesystem features: filetype sparse_super large_file
debugfs:  features ^needs_recovery
Filesystem features: filetype sparse_super large_file
debugfs:  quit

# tune2fs -l /dev/loop1 | grep -i filesystem
Filesystem volume name:   <none>
Filesystem UUID:          a1c20f0a-b85d-415e-bb39-0ab111dd9e58
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      filetype sparse_super large_file
Filesystem state:         clean with errors
Filesystem OS type:       Linux

# e2fsck -n /dev/loop1
e2fsck 1.32 (09-Nov-2002)
Group descriptors look bad... trying backup blocks...
e2fsck: Invalid argument while checking ext3 journal for /dev/loop1

# 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 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:

------------------------------------------------------------------------------
# ~/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
------------------------------------------------------------------------------

Suggestions for what to do next (including "just give up, dude" :-) are
welcome.

Thanks,
Erez.




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