Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Dai Ngo <dai.ngo@oracle.com>
CC:     Jeff Layton <jlayton@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] NFSD: enable support for write delegation
Thread-Topic: [PATCH v3 2/2] NFSD: enable support for write delegation
Thread-Index: AQHZiRjK2+pv1cqK90qCm9rFy+BQfK9gBbuAgAA/mgCAAAFTAIAADK0AgAAAi4A=
Date:   Thu, 18 May 2023 18:03:33 +0000
Message-ID: <3A7E2D1B-B24B-4920-85EF-D6AE029B57D6@oracle.com>
References: <1684366690-28029-1-git-send-email-dai.ngo@oracle.com>
 <1684366690-28029-3-git-send-email-dai.ngo@oracle.com>
 <1B8D8A68-6C66-4139-B250-B3B18043E950@oracle.com>
 <21ad5e62-b3d1-2f74-d3fb-819f4e6a2325@oracle.com>
 <C3B5A73F-2504-407A-9B62-A130CAA5E2C9@oracle.com>
 <5fab1724-090b-9c22-5555-bf3df7ea165c@oracle.com>
In-Reply-To: <5fab1724-090b-9c22-5555-bf3df7ea165c@oracle.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KzE07w83zKH+VlpaqbTjcLIFlzZggqqm5fD4KB//AgYO7chSCvTpzIN5+3Eh?=
 =?us-ascii?Q?VCJ+FqoJXFOpwtLuslpYArWT8L2HhIMDZEzTud9Rp2gUqsH/gt3To4uRATYQ?=
 =?us-ascii?Q?yno8haCgTiczIsgjg1xGZ0FRIlD6ztPSzy7I/+JdQiJB8zKWhmUXQZqxoWqN?=
 =?us-ascii?Q?yQFNYAoFCH0KRYShp1SZKdPM+pf9fWB3bjhPyY438YT0A43PRlP1B+4rx1GB?=
 =?us-ascii?Q?URZbXs8dLDNk0ghxd0xnxu1k0Z4FQ4qCgSzNZ4U1w3ciHY2eLPDd5YNF+ZmS?=
 =?us-ascii?Q?hw7T/1lbANX7ssA0N8K4UFjNIJ0ChELg70QKdMQKoh9/9nRz8tHux6zfikTE?=
 =?us-ascii?Q?XvbDsuRmoTDtqcpkC0QHuveU0BezCcPtzDtyGM6xk8WV4F4pTf14rPtQAJGx?=
 =?us-ascii?Q?3N9hMJRhDKC2RvQVT3pK7D2uGY8p0R5jVoxh4v/ILh7ORzLUbJ+vHvq/ORR6?=
 =?us-ascii?Q?5zr9Fi7K9JyBTtt/XJE43y2SCYe+DwQ7dl0in16xMSFGQo5hfDoUSJvM7Ypv?=
 =?us-ascii?Q?5dnrNmyYOZ/B92e4yKvWAEp/T40ozpvqoc152pRScIYWGTyPUtUwC14zp4YD?=
 =?us-ascii?Q?pUOjKYyxND1TSTcHIlBTRVDZM7vET4y1mml2j7eyEz7ayGpRwhQaPXlbfJw3?=
 =?us-ascii?Q?jOPijqbMRPiejDoqZ0Lge+mkIf2c+BhELztzEyOzAtrAnnfV1FVXdEjF7ZOB?=
 =?us-ascii?Q?zR5fGys3ugh3Mqb+cwmgYIH5mSsrxJUWnxrPaFincftu7XPP2t++zf7yIT2N?=
 =?us-ascii?Q?NY376Bhaxd+8EoqkTlN5Mm0DjPyha3Wuzw+58Vgn9MUQPZifZFM9gymfIRsy?=
 =?us-ascii?Q?mLeFESEFXQ0e0wizAx8zkrgFQEoSdOCQPhvQamNDyGu6hh67Vh78lqc6kbHN?=
 =?us-ascii?Q?chg+Ut6NEskmO6Yl64ROSjjzE6uHvW6I9naN++cR7DOV2S10AzYTdIm2qiG9?=
 =?us-ascii?Q?YuG7sDqHZyoMrGjk/LiO1cwniAcy9UXuevlL42hL+ynivkab5aIVY7UQgqSy?=
 =?us-ascii?Q?dXqBKFEZkFmAAOzZIM97Oa3LtOHeNzyGEeArH7vCs+7Q/OSYh+kbRlaH/T0/?=
 =?us-ascii?Q?07v3YMCNpSzFbHHon7wVWIKePXGGcaeYkJIua/sDw0GrPBNq2RrEJNqdTwQS?=
 =?us-ascii?Q?eDIsYorJOtIHVKt+fmaQs9cQXa+CIjrdLJWCdZ7vJGLZINLM6zOpnUS4hEaE?=
 =?us-ascii?Q?o1+tje2IASfK47BplzvT799bdVQ5rIVKKvwtxxIc5kkgiA8/hXgklLCRDwUZ?=
 =?us-ascii?Q?q58wQ93I0qxK3WCnFoDMpYNmyFMRwywwexsd9b8TQ4MouBoJexV+QB3tryI8?=
 =?us-ascii?Q?YEn6nKRFK1z3nh1zaGuD12EiKWjD7/Y2+Ofe21GPVh0qk44hndigCkc76SKL?=
 =?us-ascii?Q?37Cl73IAIne5bMOlNpzTz52rHT3wJ/CuBEQgSQt5sE9E/0xyFBngVpJZfxSf?=
 =?us-ascii?Q?aFR/IflYMVke8vss4EYe6qXtzhP+QqYv2wpWJXCsL/bb7fPdpkyTHKhf2gXp?=
 =?us-ascii?Q?1WN9YDTxgl0HXXTMyHYsbrBVLHW58gKL7HPlJb/vOfqbdnWYoCYU7a9ERSIP?=
 =?us-ascii?Q?KznXWTVuUCGEKJHzFh+slxkpvc9cMM7kCKF+BfNEFpAAR9dt2YG8lCBiJMiM?=
 =?us-ascii?Q?AA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6F430B8EB4EF97448FAA02C923379699@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: cCn84LBAYexPyPKytEkCVYU8JT+5Ekk9HjuiysbPOHDkFP1IzVLxjdGHAE5N9XoKOj8hT+TRgL6yEMvSIUrSLfJtgCX00sk6BZlPmTb5DOGYIRBneipNK9zLQRvaD2CmaD56b1jCAWquwUu1X1D4RtfO7j42IHgT+sM9X9Lv6p0OalJMP6gl3xe1ftZNW0J9tELrbj059br/dRDrV0DeJSilqmAmaG4cvyVsVKKE8T74sezyiEbJkoDvjGqRXIcIETgZI1SoQ6vNnSIeT7VXP8EipvYrnManMAffgq5+pl6uH/t4WHwkz7D1nWzlplBbkV30coFmDTZtWr2AVrZXqh0wSGpxyTnhiFSJUMs2z+m6XggyNl+S5ph079Zq87wEic55J5o8AzrQKt4h+nIjy2JTVGNd73lrI1rYLDyD7g0rrvGdt4kPjkfNHwIYYztM7Maj2uRhW5E8Ovnm/d0Lcd8njA8v1k4tcDlfyRsMeG/Y6LbZYIvcAyudPH7ju+VfTc6IJtoARHThvlPempAi7XAPnrLQQJrMnrwWzSoHyoD9oYG63LbhjsS3FxVpAQwN91K9pxDk7DgIqIUk7gqZXkDAqTKdsGXTo4uCDuDNVxGgqQEnK1nfwcK6BE1ZOvHFL0E74p7MmZNl95NidF/dmyc4fA8EsmdISehxpWSa8f11LEmHWug3GOqWBNlQPPJopggseCeD/TNCX1tqAPrpTTjvP/XvafPNUrkq8Id1OBiC+ADpPalDZzE8kz2bb9QVTlzlHjg7QgBw5DW1zwWb7ijVP3/vau3+x9RlHhtZPz4=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba42077f-d36f-49c1-3da6-08db57ca3231
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2023 18:03:33.9937
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OU5hVXrfYyaZj8hSTyWR36M5hrsp4gRGbaDYGoxixqKXsU8646Gv3xGH2FMaQVrxiTchm/oXmeBmI4vDQOYF5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB6037
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-05-18_13,2023-05-17_02,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0
 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 mlxlogscore=894
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2304280000 definitions=main-2305180147
X-Proofpoint-GUID: fbf7TwunbxRuz20BamIuxnRhof3kCAf1
X-Proofpoint-ORIG-GUID: fbf7TwunbxRuz20BamIuxnRhof3kCAf1
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On May 18, 2023, at 2:01 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>=20
>=20
> On 5/18/23 10:16 AM, Chuck Lever III wrote:
>>=20
>>> On May 18, 2023, at 1:11 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>>>=20
>>>=20
>>> On 5/18/23 6:23 AM, Chuck Lever III wrote:
>>>>> On May 17, 2023, at 7:38 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>>>>>=20
>>>>> This patch grants write delegation for OPEN with NFS4_SHARE_ACCESS_WR=
ITE
>>>>> if there is no conflict with other OPENs.
>>>>>=20
>>>>> Write delegation conflict with another OPEN, REMOVE, RENAME and SETAT=
TR
>>>>> are handled the same as read delegation using notify_change,
>>>>> try_break_deleg.
>>>> Very clean. A couple of suggestions, one is down below, and here is
>>>> the other:
>>>>=20
>>>> I was thinking we should add one or two counters in fs/nfsd/stats.c
>>>> to track how often read and write delegations are offered, and
>>>> perhaps one to count the number of DELEGRETURN operations. What do
>>>> you think makes sense?
>>> I'm not sure what these counters will tell us, currently we already
>>> has a counter for number of delegations handed out.
>> I haven't found that, where is it? Certainly, if NFSD already
>> has one, then no need to add more.
>=20
> num_delegations in nfs4state.c
>=20
>>=20
>> It would be nice one day, perhaps, to have a metric of how many
>> delegations a client holds. That's not for this series.
>=20
> okay.
>=20
>>=20
>>=20
>>> I think a counter
>>> on how often nfsd has to recall the write delegation due to GETATTR can
>>> be useful to know whether we should implement CB_GETATTR.
>> I hesitated to mention that because I wonder if that's something
>> that would be interesting only for defending a design choice,
>> not for site-to-site tuning. In other words, after we plumb it
>> into NFSD, it will never actually be used after CB_GETATTR
>> support is added.
>>=20
>> Do you believe it's something that administrators can use to
>> help balance or tune their workloads?
>=20
> You're right. That is just for ourselves to determine if CB_GETATTR
> is needed.

To be clear, such a counter, I agree, would be useful /to us/.
I'm just not sure how we could add something that would not
become part of the kernel/userspace API. Anyone have thoughts
about that?


--
Chuck Lever