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;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 7/9] NFSD: Use rhashtable for managing nfs4_file objects
In-reply-to: <4004BFE1-C887-4A53-9512-8A264E0361FF@oracle.com>
References: <166507275951.1802.13184584115155050247.stgit@manet.1015granger.net>,
 <166507324882.1802.884870684212914640.stgit@manet.1015granger.net>,
 <166544739751.14457.9018300177489236723@noble.neil.brown.name>,
 <EB08B095-BF02-4B5E-8CD2-12B0201328D2@oracle.com>,
 <166553144435.32740.14940127200777208215@noble.neil.brown.name>,
 <4004BFE1-C887-4A53-9512-8A264E0361FF@oracle.com>
Date:   Thu, 13 Oct 2022 08:18:36 +1100
Message-id: <166560951668.32740.3528791072339550207@noble.neil.brown.name>
Precedence: bulk

On Thu, 13 Oct 2022, Chuck Lever III wrote:
> 
> I think I stopped at the non-list variant of rhashtable because
> using rhl was more complex, and the non-list variant seemed to
> work fine. There's no architectural reason either file_hashtbl
> or the filecache must use the non-list variant.
> 
> In any event, it's worth taking the trouble now to change the
> nfs4_file implementation proposed here as you suggest.

If you like you could leave it as-is for now and I can provide a patch
to convert to rhl-tables later (won't be until late October).
There is one thing I would need to understand though: why are the
nfsd_files per-filehandle instead of per-inode?  There is probably a
good reason, but I cannot think of one.

Thanks,
NeilBrown