Re: [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow

[Daniel Phillips <phillips@google.com>]

Johann Lombardi wrote:
>>>I have no objection to this at all, but I think it will lead to a slightly
>>>more complex implementation.  We even discussed in the distant past to
>>>make large directories a series of 4kB "chunks", for fs blocksize >= 4kB.
>>>This has negative implications for large filenames because the internal
>>>free space fragmentation is high, but has the advantage that it might
>>>eventually still be usable if we can get blocksize > PAGE_SIZE.
>>>
>>>The difficulty is that when freeing dir entires you would have to be
>>>concerned with a merging a dir_entry that is spanning the middle
>>>of a 2^16 block.
>>
>>That is easy, just don't let an entry span subblocks by not letting
>>delete merge past the end of a subblock, just a minor tweak.  New block
>>initialization needs an outer loop on subblocks and that's it, I think.
> 
> 
> I've been working on a patch implementing this feature. It currently works w/o 
> htree.
> With dir_index, the difficulty is that an entry can span subblocks after a leaf
> block split.

Argh, hoist by my own petard!  That is not the only problem - we also need
to represent 64K empty records for the index blocks.  These issues need to
be dealt with in order to go past 64K blocks, and then we have so many
entries per block we probably want to rethink the leaf format anyway.  OK,
just to handle the 64K case, what is wrong with treating 0 as 64K?

Regards,

Daniel