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;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     linux-nfs@vger.kernel.org, plambri@redhat.com
Subject: Re: cto changes for v4 atomic open
Date:   Fri, 30 Jul 2021 11:14:12 -0400
Message-ID: <FCDDE052-81CE-4ACC-ABA9-9A25312BC6EE@redhat.com>
In-Reply-To: <ef395e52f3bb8d07dd7a39bb0a6dd6fb64a87a1c.camel@hammerspace.com>
References: <DF3F94B7-F322-4054-952F-90CE02B442FE@redhat.com>
 <ef395e52f3bb8d07dd7a39bb0a6dd6fb64a87a1c.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 30 Jul 2021, at 10:48, Trond Myklebust wrote:

> On Fri, 2021-07-30 at 09:25 -0400, Benjamin Coddington wrote:
>> I have some folks unhappy about behavior changes after: 479219218fbe
>> NFS:
>> Optimise away the close-to-open GETATTR when we have NFSv4 OPEN
>>
>> Before this change, a client holding a RO open would invalidate the
>> pagecache when doing a second RW open.
>>
>> Now the client doesn't invalidate the pagecache, though technically
>> it could
>> because we see a changeattr update on the RW OPEN response.
>>
>> I feel this is a grey area in CTO if we're already holding an open. 
>> Do we
>> know how the client ought to behave in this case?  Should the
>> client's open
>> upgrade to RW invalidate the pagecache?
>>
>
> It's not a "grey area in close-to-open" at all. It is very cut and
> dried.
>
> If you need to invalidate your page cache while the file is open, then
> by definition you are in a situation where there is a write by another
> client going on while you are reading. You're clearly not doing close-
> to-open.
>
> The people who are doing this should be using uncached I/O.

Thanks Trond, that corrects my ambiguity and yes - there's a much better
way.

Ben