Re: cto changes for v4 atomic open

[Trond Myklebust <trondmy@hammerspace.com>]

On Mon, 2021-08-09 at 14:20 +1000, NeilBrown wrote:
> On Wed, 04 Aug 2021, Trond Myklebust wrote:
> > On Wed, 2021-08-04 at 11:30 +1000, NeilBrown wrote:
> > 
> > Caching not a "best effort" attempt. The client is expected to
> > provide
> > a perfect reproduction of the data stored on the server in the case
> > where there is no close-to-open violation.
> > In the case where there are close-to-open violations then there are
> > two
> > cases:
> > 
> >    1. The user cares, and is using uncached I/O together with a
> >       synchronisation protocol in order to mitigate any
> > data+metadata
> >       discrepancies between the client and server.
> >    2. The user doesn't care, and we're in the standard buffered I/O
> >       case.
> > 
> > 
> > Why are you and Bruce insisting that case (2) needs to be treated
> > as
> > special?
> 
> I don't see these as the relevant cases.  They seem to assume that
> "the
> user" is a single entity with a coherent opinion.  I don't think that
> is
> necessarily the case.
> 
> I think it best to focus on the behaviours, and intentions behind,
> individual applications.  You said previously that NFS doesn't
> provide
> caches for applications, only for whole clients.  This is obviously
> true
> but I think it misses an important point.  While the cache belongs to
> the whole client, the "open" and "close" are performed by individual
> applications.  close-to-open addresses what happens between a CLOSE
> and
> an OPEN.
> 
> While it may be reasonable to accept that any application must depend
> on
> correctness of any other application with write access to the file,
> it
> doesn't necessary follow that any application can only be correct
> when
> all applications with read access are well behaved.
> 
> If an application arranges, through some external means, to only open
> a
> file after all possible writing application have closed it, then the
> NFS
> caching should not get in the way for the application being able to
> read
> anything that the other application(s) wrote.  This, it me, is the
> core
> of close-to-open consistency.
> 
> Another application writing concurrently may, of course, affect the
> read
> results in an unpredictable way.  However another application READING
> concurrently should not affect an application which is carefully
> serialised with any writers.
> 

That's a discussion we can have after Bruce and Chuck implement read
and write delegations that are always handed out when possible. Until
that's the case, there will be no changes made to the close-to-open
behaviour on the Linux NFSv4 client.

As for NFSv3, I don't see the above suggestion ever being implemented
in the Linux client because at this point, people deliberately choosing
NFSv3 are doing so almost exclusively for performance reasons.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com