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