> 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. I have understood. So for cache consistency, full file locking is needed if multiple clients can write the different parts of the same file concurrently. I think this kind of information should be documented in somewhere. If it is enough to focus on the file locking, I'm assuming it to be under "DATA AND METADATA COHERENCE" section in the nfs man page. Or, maybe it is better to update section 10.3.2 in RFC7530 with more information such as cases in which change attributes can and cannot guarantee cache consistency. Could you please tell me your opinion? Yuki Inoguchi > -----Original Message----- > From: Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> > Sent: Wednesday, January 5, 2022 12:55 AM > To: bfields@xxxxxxxxxxxx > Cc: Inoguchi, Yuki/井ノ口 雄生 <inoguchi.yuki@xxxxxxxxxxx>; > linux-nfs@xxxxxxxxxxxxxxx; neilb@xxxxxxx; mbenjami@xxxxxxxxxx > Subject: Re: client caching and locks > > 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 >
