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/hdb2 It 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 _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
