Alexander Viro wrote:
>
> On Tue, 18 Apr 2000, Stephen C. Tweedie wrote:
>
> > Most of the advantage, though, lies in the lower amount of metadata
> > required for the mapping tree if you have a larger blocksize. I'd much
> > prefer to see us end up with btree-based mapping trees and a small
> > blocksize rather than large blocks with standard indirection mapping
> > tables as a final solution, as that really ought to gain the best of
> > both worlds: small-blocksize allocation efficiency with large-blocksize
> > metadata performance.
>
> Ouch. b-tree => potentially unbound amount of blocks to be written
> during the operation. Allocation efficiency is doable with fragments -
> e.g. 32k/4k blocks/fragments should not be worse that 4k/4k in that
> respect. Besides, we _already_ have the relevant code - turning the
> preallocation logics into fragments one would not be too large change.
>
But one extent can represent a few megabyte, so 4k blocksize+extents
usually needs less metadata than 32k blocks+4k fragments.
A few months ago I proposed a simplified extent based system:
instead of 12 in-inode blocks, we store the first 6-8 extents in the
inode. Highly fragmented files and sparse files still use the current
scheme. I never had enough time to write a patch.
But allocate on flush would be difficult with such a scheme - I assume
that the pages will be flushed out of order.
-- Manfred- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:13 EST