Ext3 journal corruption?

Arkanoid · 10-10-2005, 01:28 AM

Hi there
My partition, /dev/hdb1 is acting very weird atm. Whenever, I try to mount it gives the following error:

Quote:

mount: wrong fs type, bad option, bad superblock on /dev/hdb1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

And dmesg contains the folowing line:

Quote:

EXT3-fs: journal inode is deleted.

That seems quite clear, and the reason might be that, when I run e2sfsck it says:

Quote:

[root@arwen parted-1.6.23]# e2fsck /dev/hdb1
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/hdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 8 has illegal block(s). Clear<y>? yes

Illegal block #8559 (1073741824) in inode 8. CLEARED.
Illegal block #8567 (1073741824) in inode 8. CLEARED.
Illegal block #8575 (1073741824) in inode 8. CLEARED.
Illegal block #8583 (1073741824) in inode 8. CLEARED.
Illegal block #8591 (1073741824) in inode 8. CLEARED.
Illegal block #8599 (1073741824) in inode 8. CLEARED.
Illegal block #8607 (1073741824) in inode 8. CLEARED.
Illegal block #8615 (1073741824) in inode 8. CLEARED.
Illegal block #8623 (925040641) in inode 8. CLEARED.
Illegal block #8631 (1073741869) in inode 8. CLEARED.
Illegal block #8639 (1073741824) in inode 8. CLEARED.
Too many illegal blocks in inode 8.
Clear inode<y>? yes

Restarting e2fsck from the beginning...
/dev/hdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes

And then it just loops as such. According to dumpe2fs, inode 8 contains my journal.

An option might be to remove the journal, however, tune2fs fails like this:

Quote:

[root@arwen ~]# tune2fs -f -O ^has_journal /dev/hdb1
tune2fs 1.38 (30-Jun-2005)
Illegal block number passed to ext2fs_unmark_block_bitmap #1073741824 for block bitmap for /dev/hdb1
Segmentation fault

So, is it in any way possible to recover this partition? The data it still there, according to df, and nothing except for the journal inode seems to be corrupt. I have tried, asking tune2fs to create a but, but it just fails and tells me that a journal already exists.

Any help would be much appreciated as I'm really stuck here (and in risk of loosing not-backedup data, since a backup failed)

ankscorek · 10-10-2005, 01:49 AM

as i can see from your profile u r using fc-4

so i suggest u to boot using a rescue cd

once u r logged in as root u must unmount /dev/sdb1

then u must do a file system check

u can use the following command

#fschk

im not too sure abt the command but yes the procedure is the same....

incase of any error please log it and inform in your post

Arkanoid · 10-10-2005, 07:58 AM

Yes, I am using Fedora Core 4, with kernel 2.6.13

I'm not using any type of RAID, so by /dev/sdb1 I suppose you mean /dev/hdb1.
But booting from a rescue cd shouldn't make any difference. /dev/hdb1 is normally mounted as /home/arkanoid/media, and has been umounted for this entire process (as written, my problem is that I can't mount it). The systems works perfect without the drive, since it doesn't contain any system-critical files.

Oh, and fsck is equivalent with e2fsck (i.e. gives the same error, since it's the same software afaik)

mgmax · 10-10-2005, 08:11 AM

Perhaps you could try to mount the partition as ext2, then it ignores the journal.

Max

Arkanoid · 10-10-2005, 08:30 AM

Of course

That did the trick... or, almost:
All directories except one (and lost+found), are gone. I can only see the files, that is in the main directory (now: /home/arkanoid/media), but according to df, the files and dirs must exist since there would be a lot of free space (which there aren't) otherwise.

For your convenience, or annoyance

, here's the first part of the output from dumpe2fs:

Code:

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          5e1bda81-7b79-4989-894d-784d24d00101
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Default mount options:    (none)
Filesystem state:         not clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              19660800
Block count:              39321600
Reserved block count:     1572864
Free blocks:              4679203
Free inodes:              19651185
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Tue Aug  9 23:21:41 2005
Last mount time:          Sun Oct  9 23:36:17 2005
Last write time:          Mon Oct 10 15:27:33 2005
Mount count:              5
Maximum mount count:      39
Last checked:             Sun Oct  9 19:09:45 2005
Check interval:           15552000 (6 months)
Next check after:         Fri Apr  7 19:09:45 2006
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0a857f10-3f93-4513-babf-b2801e47aa7c
Journal backup:           inode blocks

Using du -h /home/arkanoid/media, I got this (among other things):

Code:

[root@arwen hb01]# du -h /home/arkanoid/media
16K     /home/arkanoid/media/lost+found
du: cannot access `/home/arkanoid/media/Movies': Input/output error
du: cannot access `/home/arkanoid/media/Music': Input/output error
du: cannot access `/home/arkanoid/media/Anime': Input/output error
du: cannot access `/home/arkanoid/media/downloaded': Input/output error
du: cannot access `/home/arkanoid/media/.Finished': Input/output error

ankscorek · 10-10-2005, 08:38 PM

as a general query does fc-4 support resirfs filesystem?

Arkanoid · 10-10-2005, 11:44 PM

Quote:

Originally posted by ankscorek
as a general query does fc-4 support resirfs filesystem?

http://distrowatch.com/table.php?distribution=fedora
So it's possible to use, I suppose, but I haven't tried

mgmax · 10-11-2005, 02:55 PM

I dont recommend you reiserfs, I had big problems with it, a simple resize killed my partition because the reiserfs version on the computer and the rescue cd was not exactly the same.

Arkanoid · 10-11-2005, 03:08 PM

Quote:

Originally posted by mgmax
I dont recommend you reiserfs, I had big problems with it, a simple resize killed my partition because the reiserfs version on the computer and the rescue cd was not exactly the same.

Just as a simple resize has killed my ext3-system... or so I believe.

I've come to the conclusion, with help from a friend, that the pointers might be fucked-up because the resizing meddled with som inodes. I have absolutely no idea how to fix this, but I'm still looking for an answer.

ankscorek · 10-11-2005, 09:06 PM

reisrfs is a robust filesys ...however as i said runa fscheck..using your rescue cd..it will resolve your probs...

i used to face this prob when i used to use ext3..i did the same thing...but the day i started using reisrfs no such probs

Arkanoid · 10-12-2005, 05:02 AM

running fsck from a reszue cd didn't mak any difference (as I guessed

)
So I guess the data is definitely lost - I'll just start over