I don't know if this means anything to anyone, and since there is a 2.2.13
maybe this is old.
This is what I found in the logs this afternoon:
Oct 29 15:58:33 cola kernel: EXT2-fs error (device ide0(3,6)):
ext2_readdir: bad entry in directory #46370: rec_len is smaller than
minimal - offset=0, inode=0, rec_len=0, name_len=0
Oct 29 15:58:40 cola kernel: EXT2-fs warning (device ide0(3,6)):
ext2_free_blocks: bit already cleared for block 188420
Oct 29 15:59:06 cola kernel: EXT2-fs warning (device ide0(3,6)):
ext2_free_blocks: bit already cleared for block 189301
Oct 29 15:59:06 cola kernel: EXT2-fs warning (device ide0(3,6)):
ext2_free_blocks: bit already cleared for block 192500
...
Oct 29 16:13:12 cola kernel: EXT2-fs error (device ide0(3,6)):
ext2_add_entry: bad entry in directory #50457: rec_len is smaller than
minimal - offset=2048, inode=0, rec_len=0, name_len=0
Oct 29 16:17:28 cola kernel: EXT2-fs error (device ide0(3,6)):
ext2_add_entry: bad entry in directory #50457: rec_len is smaller than
minimal - offset=2048, inode=0, rec_len=0, name_len=0
Oct 29 16:19:24 cola kernel: EXT2-fs warning (device ide0(3,6)):
ext2_free_blocks: bit already cleared for block 188423
...
Oct 29 17:40:50 cola kernel: EXT2-fs warning (device ide0(3,6)):
ext2_free_blocks: bit already cleared for block 192895
Oct 29 17:40:50 cola last message repeated 2 times
...
Oct 29 18:20:02 cola kernel: EXT2-fs error (device ide0(3,6)):
ext2_readdir: bad entry in directory #50457: rec_len is smaller than
minimal - offset=0, inode=0, rec_len=0, name_len=0
and as you can see it took me quite a while to notice there was something
wrong.
I don't know exactly what I did at 15:58:33. The only thing that was
special today was that the ibm-jdk-1.1.8 coredumped and filled the
partition in question (and that may have been around that time), making
procmail put the mail in the inbox instead. A few of my mailfolders were
partially filled with '\0', but I first thought that had something to do
with procmail & the disk filling up.
e2fsck was not happy with the fs, and it took several runs to get it to be
quiet. Some files were lost in the process (but nothing valuable that
wasn't on last nights backup). lost+found contains a lot of files with
strange permissions. I'm keeping the partition as it is now for a while in
case someone has ideas on things too look for.
One last thing; the inodes e2fsck was complaining about were mostly in
series. Maybe that's a clue.
Linux 2.2.12, RH6.0, uptime ~10 days, egcs-1.1.2 compiled kernel,
e2fsck 1.14
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/