sysmark@physics.utoronto.ca (Mark Bartelt) (05/16/91)
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
sysmark@aurora.physics.utoronto.ca (Mark Bartelt) (05/16/91)
Upon rereading the above-referenced article which I posted earlier today, I notice that there's a minor ambiguity that I should have clarified. References to, for example, "SGI server" should really refer to an SGI server/client pair. Ditto for SunOS. I'd expect (though I don't know for certain) that the lack of atime updates is the fault (if "fault" is the correct term) of the client's NFS code rather than the server's. One thing I've not yet tried is to see what happens with respect to atime updates when a process running on an SGI client accesses files on a Sun server (ditto Sun client + SGI server). Mark Bartelt 416/978-5619 Canadian Institute for mark@cita.toronto.edu Theoretical Astrophysics mark@cita.utoronto.ca
barmar@think.com (Barry Margolin) (05/17/91)
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