summaryrefslogtreecommitdiffstats
path: root/fs/nfs/internal.h
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2012-09-14 17:24:32 -0400
committerTrond Myklebust <Trond.Myklebust@netapp.com>2012-10-01 15:33:33 -0700
commit05f4c350ee02e9461c6ae3a880ea326a06835e37 (patch)
tree847e24e55e47c06fcb46106b4922b915bb0109e6 /fs/nfs/internal.h
parente984a55a7418f777407c7edbb2bdf5eb9559b5e2 (diff)
downloadop-kernel-dev-05f4c350ee02e9461c6ae3a880ea326a06835e37.zip
op-kernel-dev-05f4c350ee02e9461c6ae3a880ea326a06835e37.tar.gz
NFS: Discover NFSv4 server trunking when mounting
"Server trunking" is a fancy named for a multi-homed NFS server. Trunking might occur if a client sends NFS requests for a single workload to multiple network interfaces on the same server. There are some implications for NFSv4 state management that make it useful for a client to know if a single NFSv4 server instance is multi-homed. (Note this is only a consideration for NFSv4, not for legacy versions of NFS, which are stateless). If a client cares about server trunking, no NFSv4 operations can proceed until that client determines who it is talking to. Thus server IP trunking discovery must be done when the client first encounters an unfamiliar server IP address. The nfs_get_client() function walks the nfs_client_list and matches on server IP address. The outcome of that walk tells us immediately if we have an unfamiliar server IP address. It invokes nfs_init_client() in this case. Thus, nfs4_init_client() is a good spot to perform trunking discovery. Discovery requires a client to establish a fresh client ID, so our client will now send SETCLIENTID or EXCHANGE_ID as the first NFS operation after a successful ping, rather than waiting for an application to perform an operation that requires NFSv4 state. The exact process for detecting trunking is different for NFSv4.0 and NFSv4.1, so a minorversion-specific init_client callout method is introduced. CLID_INUSE recovery is important for the trunking discovery process. CLID_INUSE is a sign the server recognizes the client's nfs_client_id4 id string, but the client is using the wrong principal this time for the SETCLIENTID operation. The SETCLIENTID must be retried with a series of different principals until one works, and then the rest of trunking discovery can proceed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'fs/nfs/internal.h')
-rw-r--r--fs/nfs/internal.h6
1 files changed, 6 insertions, 0 deletions
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 89560be..89a795d 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -483,6 +483,12 @@ extern int _nfs4_call_sync_session(struct rpc_clnt *clnt,
struct nfs4_sequence_args *args,
struct nfs4_sequence_res *res,
int cache_reply);
+extern int nfs40_walk_client_list(struct nfs_client *clp,
+ struct nfs_client **result,
+ struct rpc_cred *cred);
+extern int nfs41_walk_client_list(struct nfs_client *clp,
+ struct nfs_client **result,
+ struct rpc_cred *cred);
/*
* Determine the device name as a string
OpenPOWER on IntegriCloud