1. 17 7月, 2012 1 次提交
    • C
      NFS: Treat NFS4ERR_CLID_INUSE as a fatal error · de734831
      Chuck Lever 提交于
      For NFSv4 minor version 0, currently the cl_id_uniquifier allows the
      Linux client to generate a unique nfs_client_id4 string whenever a
      server replies with NFS4ERR_CLID_INUSE.
      
      This implementation seems to be based on a flawed reading of RFC
      3530.  NFS4ERR_CLID_INUSE actually means that the client has presented
      this nfs_client_id4 string with a different principal at some time in
      the past, and that lease is still in use on the server.
      
      For a Linux client this might be rather difficult to achieve: the
      authentication flavor is named right in the nfs_client_id4.id
      string.  If we change flavors, we change strings automatically.
      
      So, practically speaking, NFS4ERR_CLID_INUSE means there is some other
      client using our string.  There is not much that can be done to
      recover automatically.  Let's make it a permanent error.
      
      Remove the recovery logic in nfs4_proc_setclientid(), and remove the
      cl_id_uniquifier field from the nfs_client data structure.  And,
      remove the authentication flavor from the nfs_client_id4 string.
      
      Keeping the authentication flavor in the nfs_client_id4.id string
      means that we could have a separate lease for each authentication
      flavor used by mounts on the client.  But we want just one lease for
      all the mounts on this client.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      de734831
  2. 18 6月, 2012 1 次提交
    • T
      NFSv4.1: Fix umount when filelayout DS is also the MDS · 2a4c8994
      Trond Myklebust 提交于
      Currently there is a 'chicken and egg' issue when the DS is also the mounted
      MDS. The nfs_match_client() reference from nfs4_set_ds_client bumps the
      cl_count, the nfs_client is not freed at umount, and nfs4_deviceid_purge_client
      is not called to dereference the MDS usage of a deviceid which holds a
      reference to the DS nfs_client.  The result is the umount program returns,
      but the nfs_client is not freed, and the cl_session hearbeat continues.
      
      The MDS (and all other nfs mounts) lose their last nfs_client reference in
      nfs_free_server when the last nfs_server (fsid) is umounted.
      The file layout DS lose their last nfs_client reference in destroy_ds
      when the last deviceid referencing the data server is put and destroy_ds is
      called. This is triggered by a call to nfs4_deviceid_purge_client which
      removes references to a pNFS deviceid used by an MDS mount.
      
      The fix is to track how many pnfs enabled filesystems are mounted from
      this server, and then to purge the device id cache once that count reaches
      zero.
      Reported-by: NJorge Mora <Jorge.Mora@netapp.com>
      Reported-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2a4c8994
  3. 23 5月, 2012 7 次提交
  4. 03 3月, 2012 1 次提交
  5. 02 3月, 2012 1 次提交
  6. 15 2月, 2012 2 次提交
  7. 07 2月, 2012 1 次提交
  8. 01 2月, 2012 3 次提交
  9. 06 1月, 2012 1 次提交
    • C
      NFS: Cache state owners after files are closed · 0aaaf5c4
      Chuck Lever 提交于
      Servers have a finite amount of memory to store NFSv4 open and lock
      owners.  Moreover, servers may have a difficult time determining when
      they can reap their state owner table, thanks to gray areas in the
      NFSv4 protocol specification.  Thus clients should be careful to reuse
      state owners when possible.
      
      Currently Linux is not too careful.  When a user has closed all her
      files on one mount point, the state owner's reference count goes to
      zero, and it is released.  The next OPEN allocates a new one.  A
      workload that serially opens and closes files can run through a large
      number of open owners this way.
      
      When a state owner's reference count goes to zero, slap it onto a free
      list for that nfs_server, with an expiry time.  Garbage collect before
      looking for a state owner.  This makes state owners for active users
      available for re-use.
      
      Now that there can be unused state owners remaining at umount time,
      purge the state owner free list when a server is destroyed.  Also be
      sure not to reclaim unused state owners during state recovery.
      
      This change has benefits for the client as well.  For some workloads,
      this approach drops the number of OPEN_CONFIRM calls from the same as
      the number of OPEN calls, down to just one.  This reduces wire traffic
      and thus open(2) latency.  Before this patch, untarring a kernel
      source tarball shows the OPEN_CONFIRM call counter steadily increasing
      through the test.  With the patch, the OPEN_CONFIRM count remains at 1
      throughout the entire untar.
      
      As long as the expiry time is kept short, I don't think garbage
      collection should be terribly expensive, although it does bounce the
      clp->cl_lock around a bit.
      
      [ At some point we should rationalize the use of the nfs_server
      ->destroy method. ]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      [Trond: Fixed a garbage collection race and a few efficiency issues]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0aaaf5c4
  10. 01 8月, 2011 3 次提交
  11. 27 7月, 2011 1 次提交
  12. 13 7月, 2011 2 次提交
  13. 25 4月, 2011 1 次提交
  14. 12 3月, 2011 5 次提交
  15. 11 3月, 2011 1 次提交
  16. 07 1月, 2011 5 次提交
  17. 25 10月, 2010 4 次提交