Re: [PATCH] various allocator optimizations

[Chris Mason <mason@suse.com>]

On Fri, 2003-03-14 at 05:26, Hans Reiser wrote:

> >That would mean the parent directory counter would have to be updated
> >every time we allocated a block in any sub directory.  Plus the counter
> >would have to be inherited down the chain in deep directory structures. 
> >More importantly, I'd rather not waste space in the stat data to store
> >the information when we can get it during a search ;-)
> >
> The space usage is trivial.
> 

Grin, who are you and what have you done with the real hans ;-)  It's
two fields, one for the counter and one to point up the chain to the
real owner.  It's yet another field to maintain as objects are deleted
and created, a minor format change since old filesystem stat data won't
have the field, and requires support from fsck.

All of which is a lot of work when we can get similar info directly from
the tree.

> >
> >>How big are your packing localities tending to be?
> >
> >Not more than can be pointed to by the leaf level and the level directly
> >above it.  I know that's not very specific, but it varies by the
> >dataset.  packed tails and long directory names lead to more packing
> >localities per MB.
> >
> Which is why it is the wrong measure, yes?
> 

Well, yes and no.  The packing locality groups tree objects, and so the
idea behind the patch is to group all tree objects when they are part of
a directory tree that isn't very large.  A smart block allocator for the
tree nodes can use this information too.

In other words, my hope is this patch also makes btree searches more
efficient while walking a given directory tree, since we aren't jumping
all over the btree for each subdirectory.

-chris