1. 29 6月, 2012 1 次提交
  2. 05 6月, 2012 1 次提交
    • T
      NFSv4: Fix an Oops in the open recovery code · 1549210f
      Trond Myklebust 提交于
      The open recovery code does not need to request a new value for the
      mdsthreshold, and so does not allocate a struct nfs4_threshold.
      The problem is that encode_getfattr_open() will still request an
      mdsthreshold, and so we end up Oopsing in decode_attr_mdsthreshold.
      
      This patch fixes encode_getfattr_open so that it doesn't request an
      mdsthreshold when the caller isn't asking for one. It also fixes
      decode_attr_mdsthreshold so that it errors if the server returns
      an mdsthreshold that we didn't ask for (instead of Oopsing).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      1549210f
  3. 28 5月, 2012 1 次提交
  4. 27 5月, 2012 1 次提交
  5. 26 5月, 2012 2 次提交
  6. 25 5月, 2012 2 次提交
  7. 23 5月, 2012 3 次提交
    • C
      NFS: Force server to drop NFSv4 state · 2c820d9a
      Chuck Lever 提交于
      nfs4_reset_all_state() refreshes the boot verifier a server sees to
      trigger that server to wipe this client's state.  This function is
      invoked when an NFSv4.1 server reports that it has revoked some or
      all of a client's NFSv4 state.
      
      To facilitate server trunking discovery, we will eventually want to
      move the cl_boot_time field to a more global structure.  The Uniform
      Client String model (and specifically, server trunking detection)
      requires that all servers see the same boot verifier until the client
      actually does reboot, and not a fresh verifier every time the client
      unmounts and remounts the server.
      
      Without the cl_boot_time field, however, nfs4_reset_all_state() will
      have to find some other way to force the server to purge the client's
      NFSv4 state.
      
      Because these verifiers are opaque (ie, the server doesn't know or
      care that they happen to be timestamps), we can force the server
      to wipe NFSv4 state by updating the boot verifier as we do now, then
      immediately afterwards establish a fresh client ID using the old boot
      verifier again.
      
      Hopefully there are no extra paranoid server implementations that keep
      track of the client's boot verifiers and prevent clients from reusing
      a previous one.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2c820d9a
    • C
      NFS: Remove nfs_unique_id · ce1c8fc1
      Chuck Lever 提交于
      Clean up:  this structure is unused.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ce1c8fc1
    • C
      NFS: Use proper naming conventions for NFSv4.1 server scope fields · 79d4e1f0
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Additionally, for consistency, move the scope field into the NFSv4-
      specific part of the nfs_client, and free that memory in the logic
      that shuts down NFSv4 nfs_clients.
      
      Introduced by commit 99fe60d0 "nfs41: exchange_id operation", April
      1 2009.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      79d4e1f0
  8. 15 5月, 2012 1 次提交
  9. 28 4月, 2012 4 次提交
  10. 21 4月, 2012 1 次提交
  11. 21 3月, 2012 1 次提交
  12. 09 3月, 2012 1 次提交
  13. 08 3月, 2012 2 次提交
  14. 06 3月, 2012 5 次提交
  15. 02 3月, 2012 1 次提交
    • T
      NFSv4.1: Get rid of NFS4CLNT_LAYOUTRECALL · 0cb3284b
      Trond Myklebust 提交于
      The NFS4CLNT_LAYOUTRECALL bit is a long-term impediment to scalability. It
      basically stops all other recalls by a given server once any layout recall
      is requested.
      
      If the recall is for a different file, then we don't care.
      If the recall applies to the same file, then we're in one of two situations:
      Either we are in the case of a replay of an existing request, in which case
      the session is supposed to deal with matters, or we are dealing with a
      completely different request, in which case we should just try to process
      it.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0cb3284b
  16. 01 2月, 2012 8 次提交
  17. 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
  18. 28 8月, 2011 1 次提交
  19. 25 8月, 2011 3 次提交