Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     "bfields@fieldses.org" <bfields@fieldses.org>,
        "plambri@redhat.com" <plambri@redhat.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "bcodding@redhat.com" <bcodding@redhat.com>
Subject: Re: cto changes for v4 atomic open
In-reply-to: <08db3d70a6a4799a7f3a6f5227335403f5a148dd.camel@hammerspace.com>
References: <DF3F94B7-F322-4054-952F-90CE02B442FE@redhat.com>,
 <ef395e52f3bb8d07dd7a39bb0a6dd6fb64a87a1c.camel@hammerspace.com>,
 <20210803203051.GA3043@fieldses.org>,
 <3feb71ab232b26df6d63111ee8226f6bb7e8dc36.camel@hammerspace.com>,
 <20210803213642.GA4042@fieldses.org>,
 <a1934e03e68ada8b7d1abf1744ad1b8f9d784aa4.camel@hammerspace.com>,
 <162803443497.32159.4120609262211305187@noble.neil.brown.name>,
 <08db3d70a6a4799a7f3a6f5227335403f5a148dd.camel@hammerspace.com>
Date:   Wed, 04 Aug 2021 10:57:51 +1000
Message-id: <162803867150.32159.9013174090922030713@noble.neil.brown.name>
Precedence: bulk

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