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:     Benjamin Coddington <bcodding@redhat.com>
CC:     Jeff Layton <jlayton@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH] NFSv4: add sysctl for setting READDIR attrs
Thread-Topic: [RFC PATCH] NFSv4: add sysctl for setting READDIR attrs
Thread-Index: AQHZ3B4dgLDJ4SXOg0GwHvMHaaKXJrAEmDoAgAAJmACAAAprgA==
Date:   Thu, 31 Aug 2023 17:40:41 +0000
Message-ID: <B67A89F4-ACF4-4A53-B8CF-CA7487EFB129@oracle.com>
References: <8f752f70daf73016e20c49508f825e8c2c94f5e7.1693494824.git.bcodding@redhat.com>
 <021d9cf4ba3ee8a776d8c227858866caf6c7308d.camel@kernel.org>
 <4C7FEC52-164E-408C-A26E-611F6D7C314B@redhat.com>
In-Reply-To: <4C7FEC52-164E-408C-A26E-611F6D7C314B@redhat.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?n48x2q7SA9dZ1yCvcgaWr2J6F8+wRcZ6uL8LpmJvNRzl9FZpmRQxHmcelw0D?=
 =?us-ascii?Q?8J8aS+2375d0dRk6BjmU6MapLR+PzKqK5e1ZPq9W3DZybjEJJqtGZOYWeJzF?=
 =?us-ascii?Q?TWWAW0xJusrHnf/1bpiOCfY7eedM+ii55ucWBVnzhAInfq5DDntEn6cRFquw?=
 =?us-ascii?Q?i1aYZ3+RDkEeHKsYLw3IHA2ZWSnntBgdQSYIuIgaA10+4mWcAQBCWRCWK2R3?=
 =?us-ascii?Q?SvF7OUqFHdUQoIKj6/pkkwa/xhx7DwrU+ERQs/AEtB/EzUFUTzy0rwhhCaCI?=
 =?us-ascii?Q?pUti+NvYQlloSpTc99ZAGCxkjYwnGXxlbtguvzBxslA/oZ4rxf0a8UkZi0rr?=
 =?us-ascii?Q?auoVOPb4Elzc6lb2AE0PkeRFWZlPm2S/8ueSZWVX4qzbS9bEppobUzFyLVDC?=
 =?us-ascii?Q?VypFan0aBFFABHlVuDW3XrE0/t7QrNL9TAPfXyBrczn1oUImb6L8u4227q1a?=
 =?us-ascii?Q?vN0LtcuCUGG+yRL715mldvyipgKHt/kmvaiAtNByEVZGM40FHtnFmw1B8U6s?=
 =?us-ascii?Q?7wqUYtTaMp75+Rrv6ql5VUENQHHBSL3ut4flMOc28ma+syhaziOWH/MgPqcu?=
 =?us-ascii?Q?q/VOm8fbUZNghDGV3H8DYaN5df4DwtRMjWG8CKkywgkkEVKR6zgX8rlu08F7?=
 =?us-ascii?Q?DXQqnpmNsChuf1Qo9jYeO00VPCwiRNskKJMQwP0uMCSgcCuDYQu3e7AibvYm?=
 =?us-ascii?Q?KKfZLqAFuh86zJWbeACXGxUuRPNT18HI5quB/NZfnRRpiEloLnFfuwBOizuW?=
 =?us-ascii?Q?93LgUR4cJU1C7MwFmdUf5O6i9t7YsuTitH4DWUxp53Q9QnekB533x/dOijf0?=
 =?us-ascii?Q?4yLYVtUHGyJFye11+Ug6NdN0P4TR9jW4mPo4vgqKNAovNG7gyRRSqx5UCf8k?=
 =?us-ascii?Q?2iojwTm8cGNrOYre6GP8vRyy8mqZS8BuQPoZ9HHPhvtRAxQ1ytQ3nvV+r4J4?=
 =?us-ascii?Q?7Qga8Yg9GcX5wZ9/gd8EqIvAVh1fchJGqfurIZopyb0jZTgIJdDma4nQwRlb?=
 =?us-ascii?Q?tmRb1YsZCZuDWrKtR/1oQusTe3okP3uuS+AxT3GzLlLRqEqgHwbq8AGXMxAc?=
 =?us-ascii?Q?76Cr9PAmFuqG3G+cQW8Uuf5+gXFSSl9n1xArhp4Fd9GURRVFiLEhPzB9htU5?=
 =?us-ascii?Q?g0XeZd2NDMeHV4q1kAhhF+5jUkjTwgdd5g9845eypgGgy9BXs2eN8X7wA/tx?=
 =?us-ascii?Q?o7GY1empxlZchOIvcTtPkavNQeZMteGu1ToBEc9Jd+tZ5oDxZlTkptTZ3c1Z?=
 =?us-ascii?Q?L+LD/BkgW9X08WXpfPmm7uJY+Sf6sE8j9pYiCWUZJRbX7VKFpTlR6IuCQiYn?=
 =?us-ascii?Q?pLChpqVbPqaNcfKuJIffgSJbIapjL+9qaJk/C9YBXvacGYY+HMq7v98LM6mI?=
 =?us-ascii?Q?6H4YGPICc3O2siDVMtq4xLFEN2cQzX7EJ+Jslqpp3rEndHNPpFm53p/+DRC7?=
 =?us-ascii?Q?C0/w7v7y2u5TZUXbOiGlazbwpH38Q+/eCJZ+rilZKUNOk6kj6iS7SH3fGz/E?=
 =?us-ascii?Q?L2EZNUNrgQPNkErTtB5xg0aKpAG9UoUwOwUpOB6sSsSTmX2+HK3crluoGwk2?=
 =?us-ascii?Q?MyfdSjZ8YhyqbCnVaWvjYesskWIJRFJ2zJSVToDG3s8UuHVZS5/pbnb47+AI?=
 =?us-ascii?Q?nA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BF3A410BFD7F7949BEA5493F0095F142@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: OZiaO/P7WUelD1xqP22dHY5DUrs0LYNOY98gJR6/EplA1m78WEgSp/kC7D7s2d/KUifRQN254CDNGq30k4Wc4ve7kcm/GTenBCZQDXEvXryvu8tQa++cDzKVvpOhNoATzNUD5HZQo/w3uy2tH4Snpk28Krep1j7UjC/p6WSU5Ka3VRCXgs6VjHl2dQ8hvv5pb7Nf9KtfmRLA04Hy6+eXjWlOQaQ+CrLrrbd4P3HloLDcrO5r5ik9/1b5Bs8f4x7evF+c1vnGztTC522NeLS7PTCGrGLduua0PhB45YoI3cybBUbckCH4WGKxT8nSn4GwBh3DkZiw1z/7YWsfnYhh1bI7mo/qjoWicAXzhJZwpeWug5FhpVvmWZoDzkzUpRJg6N6ra8Qo2RRk05XaOysEMkTRTmT1Gh6tlsR8RpOVk83muVSHBr3SgH/Ail8uDYCYp+570p3OONF1CHfXmywMFl9fPc2M2CmEprsn8zXNnr4ijR0Vps3k/LT/Y0b5L+nHLlHZdkDjA+twZ8jRBz6KR7lGUyxx0TVXJfHp6cuCFLmkiFB4QgW0rOsDhrQT7pd0ILZLTM/8y/l2r5hxhFiZvGEUEhHquH6PcVHzHr40zS5QVSQV2uVzaETPpKkkgBvz27V95c+7n4gkD24inH++cIvX1OxFLpNK/VBCOIsOD2v1/4ylEq88NS/tW5J/ANz8GY5BiDz8R1AFOR7m43NhUKAXFciT9Z78XdEVp7nBJygNEOJpHWqfo/By0mjbAwmfV2GclPaszgC99bZ5ZDH5fpxcDkNBtaR+ynt6u7PfcxaeJzpLrLUP5IbxvsoMnP7a
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: 5cd5b985-c905-4f72-74e3-08dbaa4965b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2023 17:40:41.8201
 (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: ItmLF799GGbRFEmMB996/uoycLjKAysOFs5jgKn5rWytB8AOwOZL8kdqKLEhGjVq7FNaEawlgiKSEu76pTQyWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7218
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26
 definitions=2023-08-31_15,2023-08-31_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 malwarescore=0
 bulkscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000
 definitions=main-2308310158
X-Proofpoint-ORIG-GUID: 2kYurHvuM0G2_w3gtblmK3SMmtU4SmtA
X-Proofpoint-GUID: 2kYurHvuM0G2_w3gtblmK3SMmtU4SmtA
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        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 Aug 31, 2023, at 1:03 PM, Benjamin Coddington <bcodding@redhat.com> wr=
ote:
>=20
> On 31 Aug 2023, at 12:28, Jeff Layton wrote:
>> This doesn't seem worthwhile to me. We have a clear reason to add
>> WORD0_TYPE to "basic" READDIR, which is that we want to be able to fill
>> out the d_type for getdents.
>=20
> Yeah, and exposing all the bits might create some interesting effects.

I'm wary of adding a permanent knob, but I don't see a problem
leaving this patch out on the mailing list if there are one or
two folks who will actively try this out in a multi-server-
implementation environment (say, at bake-a-thon).

There are two sides to the trade-off:

- If the client can pick up more information in a READDIR,
there might be other places where it doesn't need another
synchronous round trip. (and of course, watch out for any
corner cases that might trigger a CB_RECALL/DELEGRETURN).

- A particular server implementation (I recall OnTAP had an
issue) might not have a large cache for file attributes,
and that would turn requests for additional attributes into
extra multiple short metadata reads in the server's filesystem.

Performance studies would be interesting, and I bet this is
something a grad student could experiment with using one of
the "captured trace" workloads that academics have floating
around (or at least they used to have them).


>> I don't see the same sort of rationale for fetching other attributes. It
>> would just be priming the inode cache with certain info. That could
>> useful for some workloads, but that seems like sort of a niche thing.
>=20
> The issues I frequently see around READDIR are that we keep micro-optimiz=
ing
> and regressing in another place.  If we set WORD0_TYPE, there's a non-zer=
o
> chance someone might start yelling about it in awhile because their serve=
r
> takes longer to query the inode.  Its nice we have the option to give the
> power back the user sometimes without needing to grow a mount option, or =
use
> a module param (which would appply to the whole system) - so this was a f=
un
> example.
>=20
>> Adding more info also reduces the number of entries you can pack into a
>> READDIR reply, which is makes it easier to trigger cookie problems with
>> creates and deletes in large directories.
>=20
> I don't think those two things are related for filesystems with stable
> cookies, or I'm not understanding you.
>=20
> I'm in favor of the default READDIR asking for type.

I say test/measure first, but I don't object to the idea.


--
Chuck Lever