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: <dfe4f6ad0420a67b9ae0f500324ba976d700642c.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>,
 <162803867150.32159.9013174090922030713@noble.neil.brown.name>,
 <ea79c8676bea627bb78c57e33199229e3cf27a9c.camel@hammerspace.com>,
 <162804062307.32159.5606967736886802956@noble.neil.brown.name>,
 <dfe4f6ad0420a67b9ae0f500324ba976d700642c.camel@hammerspace.com>
Date:   Mon, 09 Aug 2021 14:20:26 +1000
Message-id: <162848282650.22632.1924568027690604292@noble.neil.brown.name>
Precedence: bulk

On Wed, 04 Aug 2021, Trond Myklebust wrote:
> On Wed, 2021-08-04 at 11:30 +1000, NeilBrown wrote:
> 
> Caching not a "best effort" attempt. The client is expected to provide
> a perfect reproduction of the data stored on the server in the case
> where there is no close-to-open violation.
> In the case where there are close-to-open violations then there are two
> cases:
> 
>    1. The user cares, and is using uncached I/O together with a
>       synchronisation protocol in order to mitigate any data+metadata
>       discrepancies between the client and server.
>    2. The user doesn't care, and we're in the standard buffered I/O
>       case.
> 
> 
> Why are you and Bruce insisting that case (2) needs to be treated as
> special?

I don't see these as the relevant cases.  They seem to assume that "the
user" is a single entity with a coherent opinion.  I don't think that is
necessarily the case.

I think it best to focus on the behaviours, and intentions behind,
individual applications.  You said previously that NFS doesn't provide
caches for applications, only for whole clients.  This is obviously true
but I think it misses an important point.  While the cache belongs to
the whole client, the "open" and "close" are performed by individual
applications.  close-to-open addresses what happens between a CLOSE and
an OPEN.

While it may be reasonable to accept that any application must depend on
correctness of any other application with write access to the file, it
doesn't necessary follow that any application can only be correct when
all applications with read access are well behaved.

If an application arranges, through some external means, to only open a
file after all possible writing application have closed it, then the NFS
caching should not get in the way for the application being able to read
anything that the other application(s) wrote.  This, it me, is the core
of close-to-open consistency.

Another application writing concurrently may, of course, affect the read
results in an unpredictable way.  However another application READING
concurrently should not affect an application which is carefully
serialised with any writers.

Thanks,
NeilBrown