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.
Dan Taylor
Dan Taylor
Sr. Staff Engineer
WD Branded Products
949.672.7761
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
> -----Original Message-----
> From: Theodore Tso [mailto:[email protected]]
> Sent: Friday, July 09, 2010 5:04 AM
> To: Daniel Taylor
> Cc: [email protected]
> Subject: Re: Repost (from LKML): EXT3 FS and 64K blocks error
>
>
> 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.
I guess we'll find out how well they work ;) we're putting them into
pre-production test now. The main reason is that we're building a NAS
that will see significant use as a media server (we hope) and we do see
a performance improvement with the larger file system blocks in our
engineering tests.
>
> Is there a particular reason why you care about this with
> ext3? Ext4 does
> provide a superset of the features in ext3...
We're switching to ext4. I just thought someone might want to take
a look at the error message. I can do some more testing, next
week, if there are suggestions of what to try.
>
> -- Ted
>
>
On Fri, Jul 09, 2010 at 03:32:22PM -0700, Daniel Taylor wrote:
> We're switching to ext4. I just thought someone might want to take
> a look at the error message. I can do some more testing, next
> week, if there are suggestions of what to try.
I can try to dig up the patch we used to fix 64k block sizes for ext4,
and backport it to ext3, but to be honest I'm pretty overbooked
already as it is, and in general we've been trying to keep ext3
stable, which means in practice, bug fixes only. The question is
whether 64k blocksize support is considered a bug fix or a new
feature.... so if you're switching to ext4 anyway, I'd probably just
not bother trying to fix it for ext3...
- Ted
On 2010-07-09, at 16:32, Daniel Taylor wrote:
> I guess we'll find out how well they work ;) we're putting them into
> pre-production test now. The main reason is that we're building a NAS
> that will see significant use as a media server (we hope) and we do see
> a performance improvement with the larger file system blocks in our
> engineering tests.
I suspect that the reason you see better performance with ext3 and 64kB blocksize is due to the lower per-block allocation overhead. This issue is gone with ext4 due to extents and mballoc.
>> Is there a particular reason why you care about this with
>> ext3? Ext4 does provide a superset of the features in ext3...
>
> We're switching to ext4. I just thought someone might want to take
> a look at the error message. I can do some more testing, next
> week, if there are suggestions of what to try.
It would be interesting to see if there are still differences in performance with ext4 + 64kB blocksize. At a minimum it is good for someone to test the 64kB blocksize support (which not many people can do), and it is worthwhile to know if there is still performance to be gained from large blocksize or not.
Cheers, Andreas