Hi,
hoping that someone on this list can help me here is the Problem.
After a crash it seems the journal could not be recovered.
This is what mount gives:
root@wuehlkiste:# mount -t ext3 /dev/hdb2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/hdb2,
or too many mounted file systems
and this is the corresponding logfile-entry:
Nov 27 11:16:13 wuehlkiste kernel: attempt to access beyond end of device
Nov 27 11:16:13 wuehlkiste kernel: 03:42: rw=0, want=66849792, limit=2498107
Nov 27 11:16:13 wuehlkiste kernel: JBD: IO error reading journal superblock
Nov 27 11:16:13 wuehlkiste kernel: EXT3-fs: error loading journal.
fsck failed as well:
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
AT last here's what tune2fs -l gives:
root@wuehlkiste:# tune2fs -l /dev/hdb2
tune2fs 1.27 (8-Mar-2002)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 60ae4fae-f11b-4156-ade8-1aa1b63d3bc5
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 262144
Block count: 524112
Reserved block count: 26205
Free blocks: 185025
Free inodes: 242316
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Last mount time: Mon Nov 25 12:40:35 2002
Last write time: Mon Nov 25 13:49:25 2002
Mount count: 16
Maximum mount count: -1
Last checked: Sun Nov 17 18:40:27 2002
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 8
Journal device: 0x0000
First orphan inode: 0
Even clearing the has_journal and needs_recovery flags produced the same
output using fsck as above.
Running e2salvage on this backup-partition (/dev/hdb1 is the 'real'
partition, /dev/hdb2 was written using dd) didn't help much as well.
Hoping for some suggestions how to safe my data, since last backup was two
month old :-(
Regards
--
Stephan Wiehr
http://www.asta.uni-sb.de/~lynx/
"Always remember: You're unique,
just like everyone else."
On Wed, Dec 04, 2002 at 02:14:28PM +0100, Stephan Wiehr wrote:> fsck failed as well: > 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/hdb2It sounds like the journal inode got corrupted... (I'm starting to think that it might be a good idea to back up the journal inode information somewhere else, just for robustness's sake; what I'm currently thinking about is an extent map which is stored in a block pointed to by a superblock field.)> 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.... Hmm... things to try: 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. 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. 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. - Ted