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--