Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpl-opus!jewett
From: jewett@hpl-opus.HP.COM (Bob Jewett)
Newsgroups: comp.sys.hp
Subject: Re: Backup over net (Was Re: NFS Super users?)
Message-ID: <63300007@hpl-opus.HP.COM>
Date: 27 Jul 89 18:44:38 GMT
References: <2924@helios.ee.lbl.gov>
Organization: HP Labs, High Speed Electronics Dept., Palo Alto, CA
Lines: 27

> >  "find <nominiated file systems> -depth -print | cpio -oacxBC > /dev/rmt/0h"
> 
> This is not a clever idea. Recursive traverses of a remote file system
> with something like find or ls -R will stress the fileserver to a high
> degree. (Try it and watch the load average on the client and server go
> through the roof while the perfomance of both gets so bad that they're
> both unusable.)

I just did try it.  The machine doing the find/cpio was an 835, the
filesystem being traversed was NFS-mounted from a 350.  The test (somewhat
unscientific) was the startup time for "vi /etc/hosts" (1.2 megabytes) on the
350, which is also the fileserver for 15 other systems.  It took only about
twice as long to start (30 seconds) as on an unloaded 350 (~15 seconds).

On what sort of configuration do you have a response-time problem?

> It is much better to do this sort of thing on the machine where the
> files physically live. This saves network bandwidth and servicing
> gazillions of remote file system protocol requests and acknowledgements
> that are typically done at interrupt time on both the client and server.

We have found that the 835 can do a "du" on /nfs/server350 about twice as
fast as the 350 can do a "du" on its own disks.

Bob Jewett

[ not an official statement of the Hewlett-Packard Company ]