On Tue, 2021-08-03 at 21:16 -0400, bfields@xxxxxxxxxxxx wrote: > On Wed, Aug 04, 2021 at 01:03:58AM +0000, Trond Myklebust wrote: > > On Wed, 2021-08-04 at 10:57 +1000, NeilBrown wrote: > > > On Wed, 04 Aug 2021, Trond Myklebust wrote: > > > > > > > > No. What you propose is to optimise for a fringe case, which we > > > > cannot > > > > guarantee will work anyway. I'd much rather optimise for the > > > > common > > > > case, which is the only case with predictable semantics. > > > > > > > > > > "predictable"?? > > > > > > As I understand it (I haven't examined the code) the current > > > semantics > > > includes: > > > If a file is open for read, some other client changed the file, > > > and > > > the > > > file is then opened, then the second open might see new data, > > > or > > > might > > > see old data, depending on whether the requested data is still > > > in > > > cache or not. > > > > > > I find this to be less predictable than the easy-to-understand > > > semantics > > > that Bruce has quoted: > > > - revalidate on every open, flush on every close > > > > > > I'm suggesting we optimize for fringe cases, I'm suggesting we > > > provide > > > semantics that are simple, documentated, and predictable. > > > > > > > "Predictable" how? > > > > This is cached I/O. By definition, it is allowed to do things like > > readahead, writeback caching, metadata caching. What you're > > proposing > > is to optimise for a case that breaks all of the above. What's the > > point? We might just as well throw in the towel and just make > > uncached > > I/O and 'noac' mounts the default. > > It's possible to revalidate on every open and also still do > readahead, > writeback caching, and metadata caching. > Sure. It is also possible to revalidate on every read, every write and every metadata operation. That's not the point. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
