On Fri, Jul 30, 2021 at 02:48:41PM +0000, Trond Myklebust wrote: > On Fri, 2021-07-30 at 09:25 -0400, Benjamin Coddington wrote: > > I have some folks unhappy about behavior changes after: 479219218fbe > > NFS: > > Optimise away the close-to-open GETATTR when we have NFSv4 OPEN > > > > Before this change, a client holding a RO open would invalidate the > > pagecache when doing a second RW open. > > > > Now the client doesn't invalidate the pagecache, though technically > > it could > > because we see a changeattr update on the RW OPEN response. > > > > I feel this is a grey area in CTO if we're already holding an open. > > Do we > > know how the client ought to behave in this case? Should the > > client's open > > upgrade to RW invalidate the pagecache? > > > > It's not a "grey area in close-to-open" at all. It is very cut and > dried. > > If you need to invalidate your page cache while the file is open, then > by definition you are in a situation where there is a write by another > client going on while you are reading. You're clearly not doing close- > to-open. Documentation is really unclear about this case. Every definition of close-to-open that I've seen says that it requires a cache consistency check on every application open. I've never seen one that says "on every open that doesn't overlap with an already-existing open on that client". They *usually* also preface that by saying that this is motivated by the use case where opens don't overlap. But it's never made clear that that's part of the definition. --b.
