Re: client caching and locks

["bfields@fieldses.org" <bfields@fieldses.org>]

On Tue, Jan 04, 2022 at 12:36:14PM +0000, Trond Myklebust wrote:
> On Tue, 2022-01-04 at 09:24 +0000, inoguchi.yuki@fujitsu.com wrote:
> > Hi Neil and Bruce,
> > 
> > Thank you for your comments.
> > Now I have understood that this behavior is by design.
> > 
> > > > With NFSv4 there is no atomicity guarantees relating to writes
> > > > and
> > > > changeid.
> > > > There is provision for atomicity around directory operations, but
> > > > not
> > > > around data operations.
> > 
> > So I feel like clients cannot always trust changeid in NFSv4. 
> > Should it be described in the spec?
> > 
> > For example, the following section refers about the usage of
> > changeid:
> > https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-rfc5661bis#section-14.3.1
> > 
> > It says clients use change attribute " to ensure that the data for
> > the OPENed file is still 
> > correctly reflected in the client's cache." But in fact, it could be
> > wrong.
> 
> The existence of buggy servers is not a problem for the client to deal
> with. It's a problem for the server vendors to fix.

I agree that, in the absence of bugs, there's no problem with using the
change attribute to provide close-to-open cache consistency.

The interesting question to me is how you use locks to provide cache
consistency.

Language like that in
https://datatracker.ietf.org/doc/html/rfc7530#section-10.3.2 implies
that you can get something like local cache consistency by write-locking
the ranges you write, read-locking the ranges you read, flushing before
write unlocks, and checking change attributes before read locks.

In fact, that doesn't guarantee that readers see previous writes.

--b.