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

In article <126470@sun.Eng.Sun.COM> cs@Eng.Sun.COM (Carl Smith) writes:
  [copy of my suggestion to use fstat() to synch the reader-side cache]
>
>	Oh, dear.  I do hope no one will begin to rely on characteristics
>of some NFS implementations to guarantee the correct behavior of their
>applications.  NFS runs on too many operating systems to make that a
>pleasant experience.

Actually, I tried to convey that point ... the NFS spec certainly doesn't
require that this works, and I take no responsibility for it working.
On the other hand, all the suggestions about mucking with timers have
the same feature ... the NFS spec doesn't even bound the possible lifetime
of the attributes cache timers!  In general, the consistency properties
of NFS are "specified" by the behaviour of the reference port, not by
any of the language in the spec.

>	The ``noac'' mount option that Sun and others use is a bit heavy-
>handed for this application.  It seems to me all that's needed is a cache
>flush fcntl.

Just more patches on top of kludges.  There's no intrinsic reason why
a network file system can't guarantee consistency and provide reasonable
performance at the same time; it's just that NFS has gone too far in
the "stateless" direction to avoid compromising one for the other.

-Jeff