On Fri 07-12-12 00:21:25, qixuan wu wrote: > Hi Kara, > > On Thu, Dec 6, 2012 at 8:37 PM, Jan Kara <jack@xxxxxxx> wrote: > > On Thu 06-12-12 09:13:45, Li Zefan wrote: > >> >> I found this in one log: > >> >> > >> >> Nov 14 05:26:55 kernel: EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #7225391: rec_len is smaller than minimal - offset=3952, inode=0, rec_len=0, name_len=0 > >> >> Nov 14 13:42:40 kernel: EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #7225391: rec_len is smaller than minimal - offset=4024, inode=0, rec_len=0, name_len=0 > >> >> Nov 16 17:29:40 kernel: EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #7225391: rec_len is smaller than minimal - offset=4084, inode=0, rec_len=0, name_len=0 > >> >> Nov 23 19:42:44 kernel: EXT3-fs error (device sda7): ext3_readdir: bad entry in directory #7225391: rec_len is smaller than minimal - offset=3952, inode=0, rec_len=0, name_len=0 > > Sorry for posting here in the thread but I got unsubscribed from the > > list so I don't have the beginning of the thread in my inbox. > > > > ext3 directory format is such that the last directory entry in the block > > should have length to exactly fill up the whole block. Apparently, the > > length got trimmed for some reason so we ended up before end of directory > > block looked of another directory entry there and didn't find anything. I > > will also make one observation regarding offsets. They are 3952, 4024, and > > 4084. If we subtract that from 4096 (block size), we get differences (in > > binary) 10010000, 01001000, 00001100. Interestingly these have always two > > bits set. Might be luck but need not... > > Yes, we also found the interesting things that the offset happen in > many boards are like below: > 1) 3952 > 2) 3988( 3952+36) > 3) 4024( 3988+36) > 4) 4048(4042+24) > 5) 4084(same as the rec_len of ".." file if there isn't any file). > > I need introduce the rule of the files in the dir, for example: > . > .. > current_log.txt (len is 15, rec_len is 24 when there is file after it, > the value "24" i think has relative with offset 4048) > 20120526124556.865213.txt(len is 25, rec_len is 36 when there is file after it). > 20120526124984.239475.txt(len is 25, rec_len is 36 when there is file after it). > .... > Because the rec_len is 36, it has some relative with those offset > values( the diff of those values are multiple of 36). > I need tell another thing, customer's app invoke opendir/readdir very > frequently. There are more than 1000 times, every second(the value > need to be confirmed). > > > Anyway it would be interesting to get the dump of the corrupted directory > > before e2fsck is run. You can do that by running: > > debugfs -R "dump_inode <7225391> /tmp/corrupted_dir" /dev/sda7 > > > > Then you can send the dump of the corrupted directory here. > > We have already dump of the data by debugfs. The data is very good > without error. But we just did it before fsck, even the fsck is not > giving any error. I want to know whether fsck will modify disk data > without reporting any error or not ? Ah, OK. So it seems that directory block is OK, just f_pos gets corrupted somehow. There are guards in ext3_readdir() to rescan dir block when directory is modified but maybe that's not working correctly. I don't want to burn too much time on this since this is so ancient kernel but I'd be looking in that direction... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
