repeated crashes

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

 




Hello,
I've got a problem that is not solved after an e2fsck.
What happens is that the kernel (vanilla 2.6.12) does this:

journal_bmap: journal block not found at offset 1036 on hda6
Aborting journal on device hda6.
ext3_abort called.

The filesystem is mounted with errors=panic, so the system reboots. At boot-up an e2fsck is run on /dev/hda6. Sometimes it finds errors, sometimes not. Example:

e2fsck 1.35 (28-Feb-2004)
data: recovering journal
data contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #73 (26, counted=0).
Fix? yes
Free blocks count wrong for group #74 (5071, counted=667).
Fix? yes
Free blocks count wrong for group #75 (3585, counted=2844).
Fix? yes
Free blocks count wrong (1503376, counted=1498205).
Fix? yes
data: ***** FILE SYSTEM WAS MODIFIED *****
data: 1960/1343488 files (34.2% non-contiguous), 1186650/2684855 blocks

But soon after that, the same kernel message happens again.
I've also tried a newer e2fsck, from the e2fsck-static 1.38-2 Debian package, but that one didn't solve the problem either.

Dumpe2fs output:

# dumpe2fs -h /dev/hda6
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name:   data
Last mounted on:          <not available>
Filesystem UUID:          beb02481-d5a9-40b3-8d25-ff412629b14b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1343488
Block count:              2684855
Reserved block count:     134242
Free blocks:              1550359
Free inodes:              1341562
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
Filesystem created:       Wed Jan  2 22:35:26 2002
Last mount time:          Thu Sep 22 00:16:41 2005
Last write time:          Thu Sep 22 00:16:41 2005
Mount count:              1
Maximum mount count:      -1
Last checked:             Thu Sep 22 00:16:40 2005
Check interval:           0 (<none>)
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:      a1a3ccb8-023e-41ec-8af1-b2221c8da6b4
Journal backup:           inode blocks

Then when I look at the journal inode:

# debugfs /dev/hda6
debugfs 1.35 (28-Feb-2004)
debugfs:  stat <8>
Inode: 8   Type: regular    Mode:  0600   Flags: 0x0   Generation: 0
User:     0   Group:     0   Size: 33554432
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8304
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3c33d186 -- Wed Jan  2 22:35:34 2002
atime: 0x00000000 -- Wed Dec 31 19:00:00 1969
mtime: 0x3c33d186 -- Wed Jan  2 22:35:34 2002
BLOCKS:
(0-11):521-532, (IND):533, (12-1035):534-1557, (DIND):1558
TOTAL: 1038

debugfs:  bmap <8> 1035
1557
debugfs:  bmap <8> 1036
0

It seems a lot of blocks are not allocated! That is wrong, isn't it? Shouldn't e2fsck repair this then?

Eric

_______________________________________________

Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux