On Tue, 2022-01-04 at 10:32 -0500, bfields@xxxxxxxxxxxx wrote: > 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. > It does if you are doing full file locking. I agree it will not, if you are doing partial file locking. IOW: If two clients can potentially both write to different parts of the same file at the same time, then that the change attribute is insufficient to determine whether or not that was indeed what happened. However if only one client can write to the file at any time, then the change attribute check should be sufficient, given a NFSv4 spec compliant server. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
