Xref: utzoo comp.unix.ultrix:7408 comp.protocols.nfs:2377 Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!terra.Eng.Sun.COM!brent From: brent@terra.Eng.Sun.COM (Brent Callaghan) Newsgroups: comp.unix.ultrix,comp.protocols.nfs Subject: Re: nfsd 4, why, and how to tune... Message-ID: <14093@exodus.Eng.Sun.COM> Date: 28 May 91 18:54:13 GMT References: <119@janis.UUCP> Sender: news@exodus.Eng.Sun.COM Followup-To: comp.unix.ultrix Lines: 28 In article , jim@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@Eng.Sun.COM phone: (415) 336 1051