Re: cto changes for v4 atomic open

["bfields@fieldses.org" <bfields@fieldses.org>]

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.

--b.