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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
