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@lists.nfs-ganesha.org
Cc: Frank Filz <ffilzlnx@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