Re: can anyone explain this state?

[Greg Banks <gnb@sgi.com>]

On Wed, Aug 17, 2005 at 08:39:52AM -0400, Trond Myklebust wrote:
> on den 17.08.2005 Klokka 08:26 (-0400) skreiv Peter Staubach:
> > Trond Myklebust wrote:
> > >This is done using asynchronous writes. Much faster, and no need (on
> > >NFSv3) to wait for the disk before sending the next request.
> > >
> > >The reason is that on 2.4 kernels (and early 2.6 kernels) we could only
> > >do synchronous writes when you set wsize < PAGE_SIZE.
> > >
> > 
> > Maybe I am misreading the commands being run, but they look like they would
> > generate all NFS READ traffic.  It appears to be copying from an NFS mounted
> > file system to /tmp, a local file system.
> 
> Oops. errno=ENOCOFFEE... You are quite right.
> 
> Yep. That would indeed put the differences down to caching.

Trond, your comments also apply for READs with rsize<PAGE_SIZE; 2.4
will do sync reads on the wire in this case.  The performance drop
is not as dramatic as with writes because the server is doing its own
local readahead, which can't happen for writes, but there's still
a performance drop due to lack of parallelism on the wire.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs