Hello, while testing the dirshrink patch, I found that sometimes intermediate htree nodes end up with their fake_dirent's name_len and file_type not being zero. e2fsck will then consider the htree to be corrupted as it doesn't recognise that these blocks contain dx_nodes. As far as I understand it, this happens sometimes when ext4_dx_add_entry() has to create a new index node and calls ext4_append(). In the end ext4_getblk() is called and it might get a buffer that has BH_Uptodate set, causing ext4_getblk() to not zero it out and leave the old content intact. I can reproduce this with plain linux-2.6.30.5. To produce this I use a nearly full filesystem and continuously create new files in one directory while removing other directories/files at the same time. Do I understand it correctly, that it happens when the newly allocated block (for the new index node) was very recently used by another file/directory, so that it is still in the buffer cache? But it surprises me that it doesn't happen more often. Andreas Schlick -- 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