Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [PATCH v2 4/6] NFS: Add READ_PLUS data segment support
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <2c46295c6a6e748947af226dc470f7e35a2c6e82.camel@gmail.com>
Date:   Thu, 20 Feb 2020 13:54:15 -0500
Cc:     Trond.Myklebust@hammerspace.com,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1B830F5-882A-468A-88C4-6015DB557376@oracle.com>
References: <20200214211227.407836-1-Anna.Schumaker@Netapp.com>
 <20200214211227.407836-5-Anna.Schumaker@Netapp.com>
 <AAF85957-285A-42BF-993D-7EB4843E2ED2@oracle.com>
 <7621b7d84295dd3086e2036f8cb389ceb47cbbc2.camel@gmail.com>
 <CD23428B-4105-4A52-864D-73CFA64E4551@oracle.com>
 <cbff77a5175b448e955fafc45b5c80b3dcff0f5b.camel@gmail.com>
 <93E71BBA-029B-44AE-B580-0332E157D0A2@oracle.com>
 <2c46295c6a6e748947af226dc470f7e35a2c6e82.camel@gmail.com>
To:     Anna Schumaker <schumaker.anna@gmail.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Feb 20, 2020, at 1:35 PM, Anna Schumaker <schumaker.anna@gmail.com> =
wrote:
>=20
> On Thu, 2020-02-20 at 13:30 -0500, Chuck Lever wrote:
>>> On Feb 20, 2020, at 1:28 PM, Anna Schumaker =
<schumaker.anna@gmail.com>
>>> wrote:
>>>=20
>>> On Thu, 2020-02-20 at 09:55 -0500, Chuck Lever wrote:
>>>=20
>>>> The down-side here is that would make NFSv4.2 on RDMA
>>>> unable to recognize holes in files the same way as it
>>>> does on TCP, and that's a pretty significant variation
>>>> in behavior. Does "noreadplus" even deal with that?
>>>=20
>>> Setting "noreadplus" just causes the client to use the READ =
operation
>>> instead,
>>> so there should be no difference between v4.1 and v4.2 if the option =
is set.
>>=20
>> My concern is the difference between NFSv4.2 with noreadplus
>> and NFSv4.2 with readplus. The former is not able to detect
>> holes in files on the server, but the latter is.
>=20
> The client could still use lseek to detect holes. The client throws =
away the
> hole information after xdr decoding, and zeroes out the corresponding =
pages for
> the page cache.

Then maybe that's an optimization for another day. The READ_PLUS
reply can have hole information. The client could save itself some
SEEK_HOLE operations if it cached that hole information somehow.

But if "readplus" and "noreadplus" result in exactly the same hole
retention behavior on our client, I guess there's no harm in using
"noreadplus" instead, except for possible performance regression.

An alternative to making "noreadplus" the default would be to
temporarily add "noreadplus" semantics to the "proto=3Drdma" mount
option, as a separate patch; maybe after some performance results
show that it is necessary. That would keep the mount interface a
little less complicated.


--
Chuck Lever