1. 17 May, 2016 1 commit
  2. 28 Dec, 2015 1 commit
  3. 15 Oct, 2015 2 commits
  4. 27 Aug, 2015 1 commit
  5. 22 Jul, 2015 1 commit
  6. 27 Jun, 2015 1 commit
  7. 03 Feb, 2015 1 commit
  8. 05 Jan, 2015 1 commit
  9. 25 Nov, 2014 2 commits
  10. 30 Sep, 2014 1 commit
  11. 12 Jul, 2014 1 commit
  12. 28 Oct, 2013 3 commits
  13. 01 Oct, 2013 1 commit
  14. 06 Sep, 2013 1 commit
    • Andy Adamson's avatar
      NFSv4.1 Use MDS auth flavor for data server connection · 0e20162e
      Andy Adamson authored
      Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
      uses the nfs_client cl_rpcclient for all state management operations, and
      will use krb5i or auth_sys with no regard to the mount command authflavor
      The MDS, as any NFSv4.1 mount point, uses the nfs_server rpc client for all
      non-state management operations with a different nfs_server for each fsid
      encountered traversing the mount point, each with a potentially different
      auth flavor.
      pNFS data servers are not mounted in the normal sense as there is no associated
      nfs_server structure. Data servers can also export multiple fsids, each with
      a potentially different auth flavor.
      Data servers need to use the same authflavor as the MDS server rpc client for
      non-state management operations. Populate a list of rpc clients with the MDS
      server rpc client auth flavor for the DS to use.
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  15. 05 Sep, 2013 5 commits
  16. 03 Sep, 2013 1 commit
  17. 08 Jun, 2013 3 commits
  18. 14 Apr, 2013 1 commit
  19. 25 Mar, 2013 2 commits
  20. 05 Dec, 2012 5 commits
  21. 26 Nov, 2012 1 commit
  22. 21 Nov, 2012 1 commit
  23. 01 Oct, 2012 2 commits
    • Chuck Lever's avatar
      NFS: Discover NFSv4 server trunking when mounting · 05f4c350
      Chuck Lever authored
      "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
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    • Chuck Lever's avatar
      NFS: Introduce "migration" mount option · 89652617
      Chuck Lever authored
      Currently, the Linux client uses a unique nfs_client_id4.id string
      when identifying itself to distinct NFS servers.
      To support transparent state migration, the Linux client will have to
      use the same nfs_client_id4 string for all servers it communicates
      with (also known as the "uniform client string" approach).  Otherwise
      NFS servers can not recognize that open and lock state need to be
      merged after a file system transition.
      Unfortunately, there are some NFSv4.0 servers currently in the field
      that do not tolerate the uniform client string approach.
      Thus, by default, our NFSv4.0 mounts will continue to use the current
      approach, and we introduce a mount option that switches them to use
      the uniform model.  Client administrators must identify which servers
      can be mounted with this option.  Eventually most NFSv4.0 servers will
      be able to handle the uniform approach, and we can change the default.
      The first mount of a server controls the behavior for all subsequent
      mounts for the lifetime of that set of mounts of that server.  After
      the last mount of that server is gone, the client erases the data
      structure that tracks the lease.  A subsequent lease may then honor
      a different "migration" setting.
      This patch adds only the infrastructure for parsing the new mount
      option.  Support for uniform client strings is added in a subsequent
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  24. 30 Jul, 2012 1 commit