On 12/04/2012 04:29 PM, Tao Ma wrote: >> 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 > ls this directory and check whether there are any errors in dmesg. > > Having said that, as this error happens 2 times for the same inode, > maybe there is a kernel bug. At least as Ted said in another mail, the > end of this buffer head seems to be cleared. So I guess next time when > you see this error, please do: > 1. use debugfs to find the disk layout for this dir > 2. read the blocks from the block device directly > 3. check whether the end of a block(from offset to the end) is zeroed. > 4. If yes, I guess there should be a kernel bug and we can go on to > investigate the code. I still don't know if it is related to htree only, but e2fsck isn't properly fixing directory issues without the "-D" option. For example I have a VM here, where the kernel frequently reports something like: > [ 304.096059] EXT4-fs (vdb): error count: 4 > [ 304.096305] EXT4-fs (vdb): initial error at 1352366631: htree_dirblock_to_tree:861: inode 3146582: block 1641814 > [ 304.096857] EXT4-fs (vdb): last error at 1352381914: empty_dir:2334: inode 3146582: block 1641814 > [86807.520052] EXT4-fs (vdb): error count: 4 and e2fsck does not report anything. Also the dir_entry_type is for some dirs wrongly reported by the kernel, but seen correctly by e2fsck (https://bugzilla.kernel.org/show_bug.cgi?id=50261). I hope to find some time to investigate that next week. I have seen it several times already, but never had the chance to investigate or to take an image. So I would really recommend to run "e2fsck -D" for the issue reported here. Cheers, Bernd Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
