From: Christoph Hellwig <hch@lst.de>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>, Dai Ngo <dai.ngo@oracle.com>,
jlayton@kernel.org, neilb@ownmail.net, okorniev@redhat.com,
tom@talpey.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/3] NFSD: Add infrastructure for tracking persistent SCSI registration keys
Date: Fri, 19 Dec 2025 06:24:35 +0100 [thread overview]
Message-ID: <20251219052435.GB29411@lst.de> (raw)
In-Reply-To: <ecc09cc9-a0c9-499d-9d47-e90aa1f1815d@oracle.com>
On Thu, Dec 18, 2025 at 11:00:52AM -0500, Chuck Lever wrote:
> > But taking a step back: why do we even need a new hash table here?
> > Can't we jut hang off a list of block device for which a layout
> > was granted off the nfs4_client structure given that we already
> > have it available?
>
> My question is: how many items will this table need to track,
> on average? at maximum?
A good question that I do not have an answer to. In my experience most
NFS deployments actually use exactly one export per client, and I don't
think I've seen a production deployment with more than a dozen exports
mounted on a single client. Then again I'm usually pretty well shielded
from the worst enterprise deployments, so who knows especially in the
days of containers. Multiply that by the number of clients.
next prev parent reply other threads:[~2025-12-19 5:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 18:13 [PATCH 0/3] NFSD: Prevent dupplicate SCSI fencing operation Dai Ngo
2025-12-15 18:13 ` [PATCH 1/3] NFSD: Move clientid_hashval and same_clid to header files Dai Ngo
2025-12-15 18:58 ` Chuck Lever
2025-12-15 20:50 ` Dai Ngo
2025-12-18 9:25 ` Christoph Hellwig
2025-12-18 19:40 ` Dai Ngo
2025-12-15 18:13 ` [PATCH 2/3] NFSD: Add infrastructure for tracking persistent SCSI registration keys Dai Ngo
2025-12-18 9:34 ` Christoph Hellwig
2025-12-18 16:00 ` Chuck Lever
2025-12-18 19:44 ` Dai Ngo
2025-12-19 5:24 ` Christoph Hellwig [this message]
2025-12-19 13:40 ` Chuck Lever
2025-12-18 19:40 ` Dai Ngo
2025-12-15 18:13 ` [PATCH 3/3] NFSD: Prevent redundant SCSI fencing operations Dai Ngo
2025-12-18 9:34 ` Christoph Hellwig
2025-12-18 19:41 ` Dai Ngo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251219052435.GB29411@lst.de \
--to=hch@lst.de \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@ownmail.net \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox