On Tue, 2021-08-03 at 16:30 -0400, J. Bruce Fields wrote: > 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. > I'm not following your logic. The close-to-open model assumes that the file is only being modified by one client at a time and it assumes that file contents may be cached while an application is holding it open. The point checks exist in order to detect if the file is being changed when the file is not open. Linux does not have a per-application cache. It has a page cache that is shared among all applications. It is impossible for two applications to open the same file using buffered I/O, and yet see different contents. So why do we need a second point check of the validity of the page cache contents when one application has already verified that the cache was valid when it opened it? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
