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

Re: ext3-Partition lost after crash !?



On Wed, Dec 04, 2002 at 10:00:52AM -0500, Theodore Ts'o wrote:
> > Even clearing the has_journal and needs_recovery flags produced the same
> > output using fsck as above.
> 
> The exact same messages?  Including an error about reading the journal
> superblock?  Are you sure about this?  That doesn't make any sense at
> all....

See:
debugfs:  open -f -w /dev/hdb2
debugfs:  features -has_journal -needs_recovery
Filesystem features: filetype sparse_super
debugfs:  quit
[/home/lynx]
root wuehlkiste:# fsck -f /dev/hdb2
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
/dev/hdb2: Invalid argument while reading block 16712447

/dev/hdb2: Invalid argument reading journal superblock

fsck.ext2: Invalid argument while checking ext3 journal for /dev/hdb2

I was confused as well since I thought this would bring me back to ext2 in
some way.

> 1) Run "debugfs /dev/hdb2", and then type command "stat <8>", and send
> me the output.  That would be useful to see what's going on with the
> journal inode.

Here it is:
root wuehlkiste:# debugfs /dev/hdb2
debugfs 1.27 (8-Mar-2002)
debugfs:  stat <8>
Inode: 8   Type: regular    Mode:  0777   Flags: 0xff00ff   Generation:
16711935
User:   255   Group:   255   Size: 71777214328144127
File ACL: 16711935    Directory ACL: 0
Links: 255   Blockcount: 16711935
Fragment:  Address: 16711935    Number: -1    Size: 0
ctime: 0x3dffe6ff -- Wed Dec 18 04:09:51 2002
atime: 0x00ff00ff -- Mon Jul 13 11:12:15 1970
mtime: 0x3dffe6ff -- Wed Dec 18 04:09:51 2002
dtime: 0x00ff00ff -- Mon Jul 13 11:12:15 1970
BLOCKS:
(0):16712447, (1):16712447, (2):16712447, (3):16712447, (4):16712447,
(5):16712447, (6):16712447, (7):16712447, 
(8):16712447, (9):16712447, (10):16712447, (11):16712447, (IND):16712447,
(DIND):16713471, (TIND):16711935
TOTAL: 15

> 2) If the journal inode is completely trashed, you can try running
> "debugfs -w /dev/hdb2", and then use the command "clri <8>".  That
> will completely blow away the journal inode.  It shouldn't be
> necessary if you've cleared the has_journal and needs_recovery
> journal, however.
> 
> 3) Before you do any of this, if you have the disk space, it would be
> useful if could somehow see the output of "e2image -r /dev/hda2 - |
> bzip2 > hda2.img.bz2", for forensic purposes.  It will produce a
> somewhat largish file, and getting that uploaded might be a problem,
> but it would be useful to see exactly what's going on.

Before I do anything like writing to the fs I'd just like to check I'm doing
things right, so here is what I did so far:
The partition that REALLY crashed is /dev/hdb1 which is 2 GB. Moving some
data freed /dev/hdb2 (2,5 GB) for 'backup' so I did a 
'dd if=/dev/hdb1 of=/dev/hdb2 bs=1024 conv=sync' (BTW: Does the bs of dd has
something to do with the blocksize of the fs - which is 4096 - don't know
about this)
So /dev/hdb1 is still 'virgin' concerning the error state (I hope!) and all
experimental stuff I did on /dev/hdb2 (like e2salvage or trying to mount it
as ext2). Still having the originally crashed partition do I need the
Imagefile of e2image or could I skip this since diskspace has now become rare
on that machine.

> Finally, upgrading to a newer version of e2fsprogs might help,
> although in this particular case, I don't think it will; the journal
> support code hasn't changed much in recent releases.

I already compiled 1.32 and at least the static fsck behaved as above.

Regards
-- 
        Stephan Wiehr
http://www.asta.uni-sb.de/~lynx/
"Always remember: You're unique,
        just like everyone else."





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