Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!mcsun!ukc!strath-cs!jim@cs.strath.ac.uk
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.unix.wizards
Subject: Re: "find" thrashes NFS servers
Message-ID: <297@baird.cs.strath.ac.uk>
Date: 4 Oct 89 14:12:19 GMT
References: <32961@ames.arc.nasa.gov>
Sender: news@cs.strath.ac.uk
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 20

In article <32961@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>Why does "find" thrash NFS servers?  Is there anything that can be done
>about it?  

Any recursive traverse of a remote file system will place a high load on
the server. The client has to make an NFS get file attributes request
for every file/directory it encounters. Find causes lots of these
requests to get generated. Servicing the requests places a high load on
the server. A UNIX NFS server handles these requests at interrupt time
and they can take a bit of time to process. If the requests arrive from
clients at a sustained high rate (i.e. as a client ploughs through a
remote filesystem), most of the CPU time will be given over to NFS
service, leaving little for anyone else.

The best answer is to stop find from wandering into a remote filesystem.
Most NFS implementations have a find command that understands a -fstype
option (or others like -mountstop) to help this. The same problem arises
from other recursive traverses: du and ls -R spring to mind.

		Jim