• Chuck Lever's avatar
    NFS: Use the same nfs_client_id4 for every server · e984a55a
    Chuck Lever authored
    Currently, when identifying itself to NFS servers, the Linux NFS
    client uses a unique nfs_client_id4.id string for each server IP
    address it talks with.  For example, when client A talks to server X,
    the client identifies itself using a string like "AX".  The
    requirements for these strings are specified in detail by RFC 3530
    (and bis).
    
    This form of client identification presents a problem for Transparent
    State Migration.  When client A's state on server X is migrated to
    server Y, it continues to be associated with string "AX."  But,
    according to the rules of client string construction above, client
    A will present string "AY" when communicating with server Y.
    
    Server Y thus has no way to know that client A should be associated
    with the state migrated from server X.  "AX" is all but abandoned,
    interfering with establishing fresh state for client A on server Y.
    
    To support transparent state migration, then, NFSv4.0 clients must
    instead use the same nfs_client_id4.id string to identify themselves
    to every NFS server; something like "A".
    
    Now a client identifies itself as "A" to server X.  When a file
    system on server X transitions to server Y, and client A identifies
    itself as "A" to server Y, Y will know immediately that the state
    associated with "A," whether it is native or migrated, is owned by
    the client, and can merge both into a single lease.
    
    As a pre-requisite to adding support for NFSv4 migration to the Linux
    NFS client, this patch changes the way Linux identifies itself to NFS
    servers via the SETCLIENTID (NFSv4 minor version 0) and EXCHANGE_ID
    (NFSv4 minor version 1) operations.
    
    In addition to removing the server's IP address from nfs_client_id4,
    the Linux NFS client will also no longer use its own source IP address
    as part of the nfs_client_id4 string.  On multi-homed clients, the
    value of this address depends on the address family and network
    routing used to contact the server, thus it can be different for each
    server.
    Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
    Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    e984a55a
nfs4proc.c 188 KB