On Tue, Jan 04, 2022 at 12:36:14PM +0000, Trond Myklebust wrote: > On Tue, 2022-01-04 at 09:24 +0000, inoguchi.yuki@xxxxxxxxxxx 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.
