Re: Re: Shrinking ext3 directories

On Sunday 23 June 2002 10:23, Andreas Dilger wrote:
> On Jun 23, 2002 09:57 +0200, Daniel Phillips wrote:
> > At the end of the overnight run with about 16,600 cycles another block has
> > been added, bringing the directory up to 397312 bytes. The four points I
> > have now make a nice logarithmic curve, i.e., the slope seems to fall off so
> > rapidly that there is not a lot to worry about here. All the same, I should
> > code a more efficient test and run a few billion cycles. Or perhaps that
> > same effort would be better spent working on the coalesce, which will turn
> > this into a moot point.
> You could probably just allocate an array of N fixed-length filenames,
> and then just do the following for a _much_ faster algorithm:
> memset(*names, 0, N * namelen);
> for (i = 0; i < cycles; i++) {
> next = rand() % N;
> if (names[next][0])
> unlink(names[next]);
> new_name(&names[next]);
> create(names[next]);
> }
> For 100k steady-state filenames this will only be a couple MB in the array.
> You can also do more to make the entire name random, because you have an
> O(1) lookup for existing file names, so it doesn't really matter how
> strange they are.

Yes, this algorithm about as simple and efficient as you can get, thanks.

> Now you have time to code the coalesce ;-).

Yep, however the next burning issue to tackle is the readdir/telldir
problem, for which we now have a workable resolution thanks to the htree
BOF last night. I'll provide details at OLS on thursday.



This email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO