7:17 p.m.
What is the scenario that has multiple clients with the same hostname?
There is a mount option to set a non-uniform client string:
migration / nomigration
Selects whether the client uses an identification
string that is compatible with NFSv4 Transparent State
Migration (TSM). If the mounted server supports NFSv4
migration with TSM, specify the migration option.
Some server features misbehave in the face of a
migration-compatible identification string. The
nomigration option retains the use of a traditional
client indentification string which is compatible with
legacy NFS servers. This is also the behavior if
neither option is specified. A client's open and lock
state cannot be migrated transparently when it
identifies itself via a traditional identification
string.
This mount option has no effect with NFSv4 minor
versions newer than zero, which always use TSM-
compatible client identification strings.
This option makes the client use one of the first two string generators below:
fs/nfs/nfs4proc.c nfs4_init_nonuniform_client_string 5653 scnprintf(str, len, "Linux
NFSv4.0 %s/%s/%s",
fs/nfs/nfs4proc.c:5653: scnprintf(str, len, "Linux NFSv4.0 %s/%s/%s",
clp->cl_rpcclient->cl_nodename, nfs4_client_id_uniquifier,
rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_ADDR));
fs/nfs/nfs4proc.c nfs4_init_nonuniform_client_string 5659 scnprintf(str, len, "Linux
NFSv4.0 %s/%s",
fs/nfs/nfs4proc.c:5659: scnprintf(str, len, "Linux NFSv4.0 %s/%s",
clp->cl_rpcclient->cl_nodename, rpc_peeraddr2str(clp->cl_rpcclient,
RPC_DISPLAY_ADDR));
fs/nfs/nfs4proc.c nfs4_init_uniquifier_client_string 5691 scnprintf(str, len, "Linux
NFSv%u.%u %s/%s",
fs/nfs/nfs4proc.c:5691: scnprintf(str, len, "Linux NFSv%u.%u %s/%s",
clp->rpc_ops->version, clp->cl_minorversion, nfs4_client_id_uniquifier,
clp->cl_rpcclient->cl_nodename);
THIS ONE:
fs/nfs/nfs4proc.c nfs4_init_uniform_client_string 5726 scnprintf(str, len, "Linux
NFSv%u.%u %s",
fs/nfs/nfs4proc.c:5726: scnprintf(str, len, "Linux NFSv%u.%u %s",
clp->rpc_ops->version, clp->cl_minorversion,
clp->cl_rpcclient->cl_nodename);
I don’t know if those will help at all.
I would be reluctant to force use of the client IP address as part of the client
identifier on Ganesha. If that’s really necessary, maybe we can make a config option to
enable that?
Frank
From: Sriram Patil [mailto:sriramp@vmware.com]
Sent: Wednesday, March 6, 2019 2:38 PM
To: devel(a)lists.nfs-ganesha.org
Cc: Frank Filz <ffilzlnx(a)mindspring.com>
Subject: Client owner collisions
Hi,
The client owner generation logic on knfs client is very simple and tries to differentiate
on the basis of NFS version and hostname. Here’s a snippet,
scnprintf(str, len, "Linux NFSv%u.%u %s",
clp->rpc_ops->version, clp->cl_minorversion,
clp->cl_rpcclient->cl_nodename);
clp->cl_owner_id = str;
This causes a problem in ganesha in case there are multiple clients connecting to ganesha
with same hostname using same NFS version. When comparing client owners, ganesha only
takes the client owner from the NFS client into consideration. But if we consider client
owner and client IP address to decide if it is the same client before expiring the state,
it will treat them as different clients and avoid unnecessary expiry.
Any thoughts?
Thanks,
Sriram