Subject: Re: changing default for UFS_DIRHASH and NEW_BUFQ_STRATEGY
To: Perry E. Metzger <perry@piermont.com>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 06/04/2005 09:53:18
--YvpO9wCO44Ze8QQC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

It drastically depends on the combination of options and hardware, and
results will vary. I made some effort to document in options(4) these
interactions.

Basically:

* If you have IDE disks with write cache on (the default), don't use
  NEW_BUFQ - you will slow throughput, forcing extra out-of-order
  seeks by not letting the drive complete background writes that lie
  between reads.  NCQ would help here, allowing the host to feed the
  drive cache more such writes while waiting for a read, which it
  can't do now because the channel can only have one outstanding
  command.

* If you have write cache off and use softdep, you really really want
  NEW_BUFQ, so your reads have a chance to jump the queue when softdep
  issues a storm of small adjacent metadata writes that the drive must
  complete one-by-one - and be prepared for processes blocking on
  filesystem access delays regardless.

* If you want to avoid the pauses with write cache off, turn off
  softdep, but that will be much slower on aggregate because you'll be
  waiting for *many* more (sync) writes to disk that softdep would
  defer and combine (until the storm).

* If you really want to feel the pauses, stack cgd between softdep and
  a no-write-cache drive without NEW_BUFQ, give it lots of memory for
  bufcache and lots of kern.maxvnodes, and hit lots of files with,
  say, a cvs update or 3 :-)

* If you have scsi or hw-raid disks with TCQ, NEW_BUFQ won't make much
  difference in all likelihood, unless your queues are constantly
  full, at which point your drive is thrashing regardless.

All of this relates to performance and suitability; all these options
seem stable to me, but I think the current defaults are correct.

(I have no experience with DIRHASH to comment on that, but I expect
it's largely orthogonal to the others, and can only help).

--
Dan.

--YvpO9wCO44Ze8QQC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFCoO1uEAVxvV4N66cRAk/KAKCdIieXwCz6xC/xiIrWrtOQyS3SFgCguli+
WtBvAb9svGF2B3LTriOV26Q=
=gQUt
-----END PGP SIGNATURE-----

--YvpO9wCO44Ze8QQC--