On Jan 6, 2023, at 1:00 AM, Wang Yugui [off-list ref] wrote:

Hi,

quoted

From: Chuck Lever <chuck.lever@oracle.com>

While we were converting the nfs4_file hashtable to use the kernel's
resizable hashtable data structure, Neil Brown observed that the
list variant (rhltable) would be better for managing nfsd_file items
as well. The nfsd_file hash table will contain multiple entries for
the same inode -- these should be kept together on a list. And, it
could be possible for exotic or malicious client behavior to cause
the hash table to resize itself on every insertion.

A nice simplification is that rhltable_lookup() can return a list
that contains only nfsd_file items that match a given inode, which
enables us to eliminate specialized hash table helper functions and
use the default functions provided by the rhashtable implementation).

Since we are now storing nfsd_file items for the same inode on a
single list, that effectively reduces the number of hash entries
that have to be tracked in the hash table. The mininum bucket count
is therefore lowered.

some bench result such as fstests generic/531 maybe useful.

Sure. I don't expect there will be much change, but one never knows.

And this patch conflict with another patch:
(v3) [PATCH] nfsd: fix handling of cached open files in nfsd4_open codepath

Yes, this is known to conflict with patches that are now in flight.
I'll rebase once those are merged.


--
Chuck Lever