[One of my mail user agents, on one of my new systems, was silently
not sending my outgoing mail.  I am now sending all such mail from my
outgoing-mail archive.  I hope that this isn't a duplicate.
I first attempted to send this meessage Fri Jan  6 13:44:14 1995.]

* James F Kennedy:
* A quick test: right after you link the new kernel, do an nm on it.  If the
* disk access more than a second (to load nm), then you're probably right, you're
* not disk buffering - if not - then you are disk buffering.

# make >& /dev/null; time wc netbsd
    1965   20692  722225 netbsd
0.1u 0.0s 0:00.90 20.0% 0+0k 84+0io 0pf+0w

Interesting.  It is read-cacheing.

* Just a thought - perhaps your / partition is near fullness and what's occuring
* is optimization?  This would be especially true if your new kernel is
* quite a bit larger than the one it's replacing (all the seeking is the moving
* of disk blocks around to the 10% tmp space left over for this purpose and back).

# df /
Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a       23915     8949    13770    39%    /

* If you think any of these are right - forward this to the bug people and the
* group - i'm not going to waste bandwidth on speculation;)

Hmmm.  Now I don't know what is going on.  It makes no sense.

It's only with mv!!!

Look:

    again# set time
    again# cat netbsd > /dev/null
    0.0u 0.0s 0:00.04 125.0% 0+0k 0+0io 0pf+0w
    again# cat netbsd > /tmp/xxx
    0.0u 0.0s 0:00.11 72.7% 0+0k 0+95io 0pf+0w
    again# cp netbsd /tmp/xxxy
    0.0u 0.0s 0:00.21 38.0% 0+0k 0+94io 0pf+0w
    again# mv netbsd /tmp/zzz
    0.0u 0.1s 0:04.50 2.4% 0+0k 91+102io 0pf+0w

My mailer must be doing the same thing that mv does or calling
mv itself.   What does mv do differently?

mv copies things doing a read/write loop moving st_blksize 
of data at once.  That should be fast.

cp copies things doing a read/write moving of 16384 bytes (MAXBSIZE)
of data at once.  That should be faster, but not by much.  Not 
by a factor of 14.

Something isn't right.

-Dave