On Jul 8, 2010, at 8:10 PM, Daniel Taylor wrote: > We're getting the following error with an EXT3 file sytem that > has 64K blocks (2.6.32.12, on a powerpc), although I don't see > any fixes for later kernels in a diff against 2.6.35-rc3): > > ext3_readdir: bad entry in directory #11: rec_len is smaller than minimal - > offset=0, inode=0, rec_len=0, name_len=0 > > That message is generated in fs/ext3/dir.c:ext3_check_dir_entry() > when called from fs/ext3/dir.c:ext3_readdir(), AFAICT. > > Did something get missed when EXT3 handling for 64K blocks was > implemented or when a new feature was added? > > FWIW, I do NOT see this on EXT4. I very much doubt anyone has ever tested 64k blocks on ext3. There were some extensions made to support 64k blocks with ext4, that had to do with encoding the directory entry rec_len fields (which is 16 bits and will overflow when trying to store the value 65536, as you have discovered). Bottom line, it's not so much that EXT3 handling for 64k blocks was ever *implemented*, as much as no one really thought about it much when they set the #define's for maximum block size supported. :-) 64k block sizes hasn't received much testing on ext4 as far as I know, but there was one developer who noted the dirent encoding problem and proposed a fix. Is there a particular reason why you care about this with ext3? Ext4 does provide a superset of the features in ext3... -- Ted -- 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
