> 
> This looks like another VM vs. buffer cache problem.
> 
> If so, the reason for this is that /bin/cp is using mmap() to read the
> source file, while cat and GNU cp (I assume) use read().  Your last
> update to the file is probably sitting in your local buffer cache, and
> hasn't yet propagated to the NFS server.  mmap() bypasses the local
> buffer cache, while read() does not.
> 
> >Could you please give me some advice whether /bin/cp can be fixed, if
> >I can use GNU cp as a full replacement or maybe I'm just doing
> >something wrong? Or even better, could you drop me a note what exactly
> >is going wrong? Is this a general NFS problem or just /bin/cp trying
> >to be too clever?
> 
> Fixing the problem requires integrating the VM system and the file
> buffer cache, which is heavy-duty kernel hacking (to put it mildly).
> 
If your analysis of the problem is correct (and I have no reason to
suspect that you are wrong), it would probably be wise to "fix" cp
to do read/writes.  That is the way the FreeBSD did it before the
merged VM/Buffer cache code was done.  It looks like cp might be depending
on semantics that just don't exist in NetBSD currently.

Note that if you mmap to read when you don't have a merged cache, it can
double the amount of memory that the buffering takes for a given file
(up until the system starts paging.)  (You have a copy of the file in
the VM cache AND in the buffer cache.)

John
dyson@freebsd.org