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. Thanks, NeilBrown
