Xref: utzoo comp.protocols.nfs:2320 comp.sys.sgi:10133
Newsgroups: comp.protocols.nfs,comp.sys.sgi
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!aurora.physics.utoronto.ca!sysmark
From: sysmark@physics.utoronto.ca (Mark Bartelt)
Subject: NFS atime (non-)update
Message-ID: <1991May16.112349.13681@helios.physics.utoronto.ca>
Followup-To: comp.protocols.nfs
Originator: sysmark@aurora.physics.utoronto.ca
Sender: news@helios.physics.utoronto.ca (News Administrator)
Nntp-Posting-Host: aurora.physics.utoronto.ca
Reply-To: mark@cita.toronto.edu
Organization: University of Toronto Physics/Astronomy/CITA
Date: Thu, 16 May 1991 11:23:49 GMT

A month or so ago, I wrote (in comp.sys.sgi) ...

| I just noticed that if a process on an NFS client exec()s a file that
| lives on an SGI NFS server, the file's atime doesn't get updated!  Is
| this a botch by SGI (i.e. does the NFS spec require that the atime be
| updated, but IRIX simply doesn't do it), or is the question of whether
| a server is meant to update the atime discretionary?

... to which SGI's Brendan Eich replied (via e-mail) ...

| Are you certain the exec'd file was not already paged in and resident
| in the client's cache?  If it were, no RPCs to the server would be done,
| so no atime update.  Please fill me in with more data, or followup to
| the net?

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?

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?

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.)

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?  And even if it's not required, is
there a good reason for SGI *not* to do it?  (Would there really be a large
performance hit as a result of doing atime updates?)

Mark Bartelt                                                  416/978-5619
Canadian Institute for                               mark@cita.toronto.edu
Theoretical Astrophysics                             mark@cita.utoronto.ca