1. 28 4月, 2012 1 次提交
  2. 21 4月, 2012 1 次提交
  3. 21 3月, 2012 1 次提交
  4. 09 3月, 2012 1 次提交
  5. 08 3月, 2012 2 次提交
  6. 06 3月, 2012 5 次提交
  7. 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
  8. 01 2月, 2012 8 次提交
  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. 28 8月, 2011 1 次提交
  11. 25 8月, 2011 3 次提交
  12. 01 8月, 2011 1 次提交
  13. 20 7月, 2011 1 次提交
  14. 13 7月, 2011 2 次提交
  15. 25 4月, 2011 1 次提交
  16. 25 3月, 2011 2 次提交
  17. 24 3月, 2011 1 次提交
  18. 12 3月, 2011 5 次提交
  19. 07 1月, 2011 2 次提交
    • C
      NFS: Move cl_state_owners and related fields to the nfs_server struct · 24d292b8
      Chuck Lever 提交于
      NFSv4 migration needs to reassociate state owners from the source to
      the destination nfs_server data structures.  To make that easier, move
      the cl_state_owners field to the nfs_server struct.  cl_openowner_id
      and cl_lockowner_id accompany this move, as they are used in
      conjunction with cl_state_owners.
      
      The cl_lock field in the parent nfs_client continues to protect all
      three of these fields.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      24d292b8
    • F
      pnfs: layout roc code · f7e8917a
      Fred Isaman 提交于
      A layout can request return-on-close.  How this interacts with the
      forgetful model of never sending LAYOUTRETURNS is a bit ambiguous.
      We forget any layouts marked roc, and wait for them to be completely
      forgotten before continuing with the close.  In addition, to compensate
      for races with any inflight LAYOUTGETs, and the fact that we do not get
      any layout stateid back from the server, we set the barrier to the worst
      case scenario of current_seqid + number of outstanding LAYOUTGETS.
      Signed-off-by: NFred Isaman <iisaman@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f7e8917a