This shouldn't really surprise anyone, but I'll point out that "newdirpref"
causes a really annoying side effect.  I noticed this because two processes
were simultaneously writing medium-size (10-100MB) files, and then attempting
to burn them to DVD.

In the Old Days, before the web, FFS would tend to put new directories in the
least full CG.  This had the effect of (usually) balancing out the CGs.  If I
created two files in separate directories, they usually ended up in different
CGs.  I could write to them at the same time, and they would end up
relatively linear on disk, because their blocks were allocated from different
pools.  (Note that this effect also helps a little with SMP, not that
NetBSD's SMP is anything to write home about.)

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.