Re: [PATCH 13/15] NFS: Discover NFSv4 server trunking when mounting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 16, 2012, at 3:05 PM, Myklebust, Trond wrote:

> On Wed, 2012-07-11 at 16:31 -0400, Chuck Lever wrote:
>> "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 the rest of
>> trunking discovery can proceed.
>> 
>> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
>> ---
>> 
>> fs/nfs/client.c    |  237 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> fs/nfs/internal.h  |    6 +
>> fs/nfs/nfs4_fs.h   |    8 ++
>> fs/nfs/nfs4proc.c  |    2 
>> fs/nfs/nfs4state.c |  186 ++++++++++++++++++++++++++++++++++++++++-
>> 5 files changed, 433 insertions(+), 6 deletions(-)
> 
> Applying: NFS: Discover NFSv4 server trunking when mounting
> error: patch failed: fs/nfs/nfs4state.c:1656
> error: fs/nfs/nfs4state.c: patch does not apply
> Patch failed at 0001 NFS: Discover NFSv4 server trunking when mounting

I can take a look.  What are you applying it to, exactly?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux