From: Dai Ngo <dai.ngo@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: chuck.lever@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: Thu, 18 Dec 2025 11:40:53 -0800 [thread overview]
Message-ID: <347f48c0-d6ac-4e38-b852-5bba071ee688@oracle.com> (raw)
In-Reply-To: <20251218093434.GB9235@lst.de>
On 12/18/25 1:34 AM, Christoph Hellwig wrote:
> On Mon, Dec 15, 2025 at 10:13:34AM -0800, Dai Ngo wrote:
>> +
>> +int
>> +nfsd4_scsi_pr_init_hashtbl(struct nfsd_net *nn)
>> +{
>> + int ix;
>> +
>> + nn->client_pr_record_hashtbl = kmalloc_array(CLIENT_HASH_SIZE,
>> + sizeof(struct list_head),
>> + GFP_KERNEL);
>> + if (!nn->client_pr_record_hashtbl)
>> + return -ENOMEM;
>> + spin_lock_init(&nn->client_pr_record_hashtbl_lock);
>> + for (ix = 0; ix < CLIENT_HASH_SIZE; ix++)
>> + INIT_LIST_HEAD(&nn->client_pr_record_hashtbl[ix]);
>> + return 0;
> I guess there is precendent in the nfsd code in using this fixed size
> hash table, but they are not very scalable. And using the rhastable
> API is actually relatively simple, so it might be easier to use that
> than rolling your own hash.
>
> If you stick to the fixes size open code hash, you should use a
> hlist_head here. There is no advantage in having a pointer to the tail
> entry for hashes, and the hlist saves half of the memory usage and
> improves cache efficiency.
>
> 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?
Yes, a simple list hang of the nfs4_client structure makes sense.
I don't think a NFS client would be configured to access too many
pNFS shares with SCSI layout type. Also, fencing is not expected
to be a frequent operation so traversing the list should not effect
the overall performance of the NFS server.
>
>> +static struct scsi_pr_record *
>> +nfsd4_pr_find_client(struct nfs4_client *clp, struct block_device *blkdev)
>> +{
>> + struct scsi_pr_record *pr_rec = NULL;
>> + struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
>> + unsigned int idhashval;
>> + dev_t bdev = blkdev->bd_dev;
>> +
>> + assert_spin_locked(&nn->client_pr_record_hashtbl_lock);
>> + idhashval = clientid_hashval(clp->cl_clientid.cl_id);
>> + list_for_each_entry(pr_rec, &nn->client_pr_record_hashtbl[idhashval],
>> + spr_hash) {
>> + if (same_clid(&pr_rec->spr_clid, &clp->cl_clientid) &&
>> + pr_rec->spr_bdev == bdev) {
>> + return pr_rec;
>> + }
> This ensures that you always have collisions for multiple bdevs of the
> same client. Why not use a hash the mixes entropy from the client id
> and the bdev?
This is no longer needed when switching to use a simple list.
>
>> +bool
>> +nfsd4_scsi_pr_fence(struct nfs4_client *clp, struct block_device *blkdev)
>> +{
>> + struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
>> + struct scsi_pr_record *rec;
>> +
>> + assert_spin_locked(&nn->client_pr_record_hashtbl_lock);
>> + rec = nfsd4_pr_find_client(clp, blkdev);
>> + if (rec && !rec->spr_fenced) {
>> + rec->spr_fenced = true;
>> + return true;
>> + }
>> + return false;
>> +}
> This function seems misnamed. It doesn't do any actualy fencing.
will fix in v2.
>
>> +extern int nfsd4_scsi_pr_init_hashtbl(struct nfsd_net *net);
>> +extern void nfsd4_scsi_pr_shutdown(struct nfsd_net *net);
>> +struct nfs4_client;
>> +extern void nfsd4_scsi_pr_del_client(struct nfs4_client *clp);
>> +extern int nfsd4_scsi_pr_add_client(struct nfs4_client *clp,
>> + struct block_device *blkdev);
>> +extern bool nfsd4_scsi_pr_fence(struct nfs4_client *clp,
>> + struct block_device *blkdev);
> Some of these are only used inside of blocklayout, so mark them
> static. For the others drop the extern. Also please keep
> struct forward declarations at the top of the file.
will fix in v2.
>
>> +
>> #else /* CONFIG_NFSD_V4 */
>> static inline int nfsd4_is_junction(struct dentry *dentry)
>> {
>> @@ -578,6 +587,13 @@ static inline int nfsd4_is_junction(struct dentry *dentry)
>>
>> static inline void nfsd4_init_leases_net(struct nfsd_net *nn) { };
>>
>> +extern inline int nfsd4_scsi_pr_init_hashtbl(struct nfsd_net *nn)
> This should be static inline.
no longer need this with a simple list.
>
>> index db9af780438b..9ae02b6d922d 100644
>> --- a/fs/nfsd/pnfs.h
>> +++ b/fs/nfsd/pnfs.h
>> @@ -67,6 +67,17 @@ __be32 nfsd4_return_client_layouts(struct svc_rqst *rqstp,
>> int nfsd4_set_deviceid(struct nfsd4_deviceid *id, const struct svc_fh *fhp,
>> u32 device_generation);
>> struct nfsd4_deviceid_map *nfsd4_find_devid_map(int idx);
>> +
>> +int nfsd4_scsi_pr_init_hashtbl(struct nfsd_net *nn);
>> +void nfsd4_scsi_pr_shutdown(struct nfsd_net *nn);
>> +void nfsd4_scsi_pr_del_client(struct nfs4_client *clp);
> These duplicate the prototypes in nfsd.h.
will fix in v2.
>
>> +struct scsi_pr_record {
>> + struct list_head spr_hash;
>> + clientid_t spr_clid;
>> + dev_t spr_bdev;
>> + bool spr_fenced;
>> +};
> This can be kept static in blocklayout.c
will fix in v2.
Thanks,
-Dai
next prev parent reply other threads:[~2025-12-18 19:41 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
2025-12-19 13:40 ` Chuck Lever
2025-12-18 19:40 ` Dai Ngo [this message]
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=347f48c0-d6ac-4e38-b852-5bba071ee688@oracle.com \
--to=dai.ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=hch@lst.de \
--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