This is mostly a CVS issue, or rather the impact of CVS's access
patterns.

For those experiencing this problem - are you running softdep?

CVS hits lots and lots of files, that means a lot of atime updates
in the first instance, and a bunch of other directory and inode
updates as files are actually pulled down.  Softdep smoothes the
load of this considerably, and probably eliminates a lot of duplicate
updates. It can also help some of the other apps not block on their
own disk updates for so long while there's disk contention going
on.

People have made the contrast between NetBSD and FreeBSD/Linux.
FreeBSD is probably using softdep by default (?), Linux is effectively
mounting async. Do the same on NetBSD, and then compare again.

Other things to help further:

  - On my laptop, in order to let the disk stay spun down more of
    the time, I run filesystems noatime,nodevmtime, further reducing
    the load and impact of CVS. With the combination of all of
    these things, I really see nothing like the problems people
    describe here -- even though the disk traffic is all going
    through cgd doing crypto in interrupt context.

  - In current, there is work under NEW_BUFQ_STRATEGY to address
    some of the other known problems with dealing with the impact of
    nasty disk access patterns. It might be worth seeing what effect
    this has, if you're willing to experiment. I haven't needed to.

--
Dan.