Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!decwrl!mogul
From: mogul@decwrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS client has out-of-date files
Message-ID: <205@jove.dec.com>
Date: 17 Oct 89 01:02:54 GMT
References: <17787@bellcore.bellcore.com> <1967@convex.UUCP> <1989Oct6.203732.12847@acd4.UUCP> <125974@sun.Eng.Sun.COM> <1989Oct9.191726.23428@acd4.UUCP>
Distribution: na
Organization: DEC Western Research
Lines: 38

In article <1989Oct9.191726.23428@acd4.UUCP> mjb@acd4.UUCP ( Mike Bryan          ) writes:
>As for the exact reason we couldn't use NFS, I'll try to give a brief
>non-proprietary description.  There are two processes, "A" and "B".
>Process A is receiving data, and putting it into a file.  On some
>types of data, it will send a message to process B, telling it there
>is data available.  Process B then reads the data from the file.  If
>everything is on a single machine, there is no problem.  The problem
>is when they are on different machines (process A on the NFS server,
>process B on the NFS client).  Then process B gets the message, and
>goes to read the file.  If it had been read "recently", as is often
>the case, the client will not have the updated data.

On fundamental philosophical grounds, I'll basically agree with
you that NFS doesn't provide the appropriate consistency guarantees
here ... people interested in this might want to read the paper
by V. Srinivasan and myself at the upcoming SOSP.  However, I think
your problem has a simple, if not entirely efficient, solution.

Since you seem to have control over the source of the program used
by Process B, I think if you have it do an "fstat()" of the file
after receiving the synchronization message and before calling "read()"
on the file, this will force the NFS client code on machine B to
check with the server.  This is not, as far as I can tell, an official
feature of the NFS specification, but is rather the way that NFS is
actually implemented (at least in the earlier reference ports).

In your application, this should not be extremely inefficient, since
you will always be paying the latency of writing the data to the server
disk once per "transaction", and so the extra cost (latency) of doing
the "getattr()" RPC (the underlying implementation of "fstat()") should
be nearly negligible.  I don't think it's a good general solution,
especially given that one doesn't always have source code for the
application.

-Jeff
P.S.: I'll make sure that someone in the Ultrix group at Digital
knows that you want the "noac" option when mounting NFS files; no
promises, of course (I'm in research).