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.
-
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