Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS atime (non-)update
Message-ID: <1991May16.181356.4997@Think.COM>
Date: 16 May 91 18:13:56 GMT
References: <1991May16.112349.13681@helios.physics.utoronto.ca>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 48

In article <1991May16.112349.13681@helios.physics.utoronto.ca> mark@cita.toronto.edu writes:
>Actually, I had suspected that the behaviour was related to caching (I've
>noticed atime non-update following read() as well as following exec(), in
>fact), but I guess the real question is:  What does NFS require, and what
>does it leave open to the whim of the implementor?

The NFS specification only describes the protocol, i.e. *how* to access
remote file systems.  It doesn't address the specific relationship between
the local operations on a client and which specific NFS operations should
result, i.e. *when* to issue particular protocol operations.  Since NFS is
intended to be OS-independent, it would be inappropriate for it to specify
the behavior at this level.

>Granted that, if a process on a client accesses something that the client
>has cached, it's silly to transfer the data from the server again.  Still,
>oughtn't the client do whatever the NFS equivalent of utime(2) is, to try
>to preserve as much of the UNIX filesystem semantics as possible?

You don't want the client doing a utime(), because its clock may not be
synchronized with the server's or other clients.  For instance, if
clientA's clock is a minute ahead of clientB's, the atime of an executable
would go backward if clientB were to execute a file less than a minute
after clientA did.

>Note that this is what SunOS seems to do.  (I don't know for certain that
>it does, but I've never seen an instance of the atime not getting updated
>under SunOS, even if a read() or exec() happens soon after a previous one,
>when (most likely) the client would have things cached.)

Since SunOS normally pages the text segment directly out of executable
files, it's unlikely that an entire executable will stay in memory for very
long, so it will frequently need to get a page from the server, thus
updating the atime.  SGI may page the text segment out to the local swap
space, so repeated accesses to the same executable don't need to access the
server.  On SunOS we appear to be able to get this behavior by setting the
sticky bit of the executable (we notice much better performance of huge
Lisp images when we do this).

>So, is Suns's behaviour mandated by the NFS spec, or is it suggested but not
>required, or is not even mentioned and just something that Sun does because
>they think it's a sensible thing to do?

Or maybe it's just an accident resulting from other design decisions.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar