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. > > Yuki Inoguchi 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. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
