On Mon, Aug 21, 2006 at 10:04:45AM -0400, Charles M. Hannum wrote:
>
> This is no longer the case.  Rather, "newdirpref" tends to fill up
> some CGs first -- often a contiguous chunk, even.  This has the
> effect of reducing the pool of CGs that these large files can come
> from.  Worse, because the full or nearly-full CGs tend to be in a
> contiguous region, as the disk fills, the "rehashing" mechanism in
> blockpref ends up hitting an even smaller number of CGs frequently.
> Worse, the policy itself tends to blindly put new directories (and
> thus their files) in the same CG much of the time anyway. The result
> of all this is that we have really bad contention, and rather often
> the two processes I referred to above end up writing files to the
> same CG, interleaving their blocks (because the block rotor is also
> just that dumb).
>
> And this culminates in me being unable to write the data faster than
> 4x to my DVD drive, because reading it back from the hard disk is
> just too damned slow.  Even though I've tested my DVD drive at 16x
> and it works just fine.
>
> This sucks.

I wonder if this effect might not be greatly reduced if the number of
CGs were greatly reduced.  SGI did some profiling on this early in XFS
development and periodically as disk sizes increased, and I am pretty
sure that their overall recommendation is still one allocation group
per processor, maximum.

They do spread new directories over allocation groups (or did last I
looked) though using an algorithm very different from that in FFS.

Yes, I'm aware that a huge blocksize is required to get less cylinder
groups, with the current FFS datastructures.  You could always use
LFS. ;-) (Actually, LFS is working well enough now that we use it as a
root file system on one of the autobuild machines).

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart