Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS and slow links
Message-ID: <6337@auspex.auspex.com>
Date: 27 Feb 91 19:48:20 GMT
References: <1991Feb26.032009.12747@Citicorp.COM> <1991Feb26.031838.12683@Citicorp.COM> <1991Feb26.151806.26335@athena.mit.edu>
Organization: Auspex Systems, Santa Clara
Lines: 32

>  It is likely that the reason linking goes slowly when creating an executable
>in an NFS filesystem is that the linker has to seek back and forth to various
>points in the file while linking.  Because of that, it isn't just a matter of
>reading in the sequential blocks of a file or writing out the sequential
>blocks of a file -- the same blocks have to be read in over and over again
>each time the linker seeks to them.

Not once those blocks end up in the buffer cache/page pool of your
system, if it buffers I/O for NFS, as most UNIX NFS client
implementations do.  Only one read from over the wire should be
necessary, assuming the object files aren't changing out from under the
linker (and if they are, you have worse problems than the performance of
the link...), and assuming that you don't have to have the buffers/page
frames containing data from the file used for other purposes (but then,
that's true if the files are being read from a local file system as
well).

>  A possible work-around to avoid this problem is to create a symbolic link
>in the directory in which you are compiling to force the linking to take place
>in a local directory like /tmp or /usr/tmp (or just to specify such a
>directory when specifying the output file name to the linker), and then mv the
>file onto the NFS partition when it's done linking.  You'll probably get a
>significant speed improvement that way.

Which would indicate that the problem isn't one of *reading* files, it's
one of *writing* them, if the only symlink is for the target of the link
- it's still reading the input object files from the same NFS file
system, it's just writing the output to a local file system.

That would be quite believable, unless your server was doing "unsafe"
asynchronous writes, or had some kind of Prestoserve-like "write
buffer", or some other trick for speeding up synchronous NFS writes.