On 2012/12/5 22:02, Tao Ma wrote:

On 12/05/2012 06:46 PM, Li Zefan wrote:

quoted

quoted

quoted

quoted

quoted

We highly doubt it's hardware failures with this frequency in mind, so
we're wondering regarding to this issue if there's some ext3 bug-fix
having merged into mainline but not in our old kernel?

Absolutely there are.  There have been 87 changes just to namei.c since 2.6.16.
You could look through git logs to see if anything looks applicable.

You might try:

ef2b02d3e617cb0400eedf2668f86215e1b0e6af ext34: ensure do_split leaves enough free space in both blocks

I've been asked to investigate this issue. Thanks for the reply!

I found this fix while searching for similar bug reports, but I don't think it
worths trying as we don't use dir_index feature.

I've collected some logs in different machines, and the error was always
triggered in ext3_readdir:

EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #6685458: rec_len is smaller than minimal - offset=3860, inode=0, rec_len=0, name_len=0
EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #9650541: rec_len is smaller than minimal - offset=3960, inode=0, rec_len=0, name_len=0
EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #11124783: rec_len is smaller than minimal - offset=4072, inode=0, rec_len=0, name_len=0
EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #52740880: rec_len is smaller than minimal - offset=4024, inode=0, rec_len=0, name_len=0
EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #52740880: rec_len is smaller than minimal - offset=4084, inode=0, rec_len=0, name_len=0

The last two errors happened on the same machine, and the same inode! One
happened in 11/22 (I was told they had run fsck later on), and one in 12/01.

So now this directory has been fscked to be right? You can try by just

right.

quoted

ls this directory and check whether there are any errors in dmesg.

no error at all.

OK, so now it is fixed by e2fsck. hmm, is there any stress inode

I'm inclined to believe the on-disk dir didn't get corrupted, and so fsck
found no errors.

creation/deletion in this dir? 2.6.16 is too older although I am not
sure whether this is a bug or not.

I don't think there're frequent file create/delete/rename ops in the log dir.