nfsd 4, why, and how to tune...

[Brent Callaghan]

In article <JIM.91May28110939 at baird.cs.strath.ac.uk>, jim at cs.strath.ac.uk (Jim Reid) writes:
> Any recursive directory traverse via NFS can be painful (du is just as
> bad as find). This is because the client makes LOTS of NFS requests -
> several read directory entries to get the file names and the file
> handles followed by a get file atributes request for each file. If the
> client is faster at sending these out than the server is at replying,
> this is bad news. The server will be bombarded with NFS requests which
> it can't service quickly enough. The requests timeout, so the client
> sends them all over again, saturating the server once more and closing
> the loop.

No, this isn't right.  The biod's on an NFS client can generate
multiple concurrent requests - but only for in I/O operations:
read and write.  A process doing a find generates lots of
READDIR's and LOOKUP's.  These are executed in the context of
the process generating them.  For each request, the process
blocks until it gets a reply from the server.  If we're assuming
that there's just one "find" process running on the client, then
there's no way that the client can "bombard" the server with
requests - it's all synchronous.

Whether you do it over NFS or locally, find is a very disk
intensive activity.
--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 Email: brent at Eng.Sun.COM
			 phone: (415) 336 1051