LinuxQuestions.org - Ext3 journal corruption?

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - Ext3 journal corruption? (https://www.linuxquestions.org/questions/linux-hardware-18/ext3-journal-corruption-371412/)

Ext3 journal corruption?

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)

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

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)

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

Max

Of course :rolleyes: 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

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

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

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.

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.

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

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