1. 26 Apr, 2013 2 commits
  2. 23 Apr, 2013 1 commit
  3. 22 Apr, 2013 1 commit
  4. 21 Apr, 2013 1 commit
  5. 20 Apr, 2013 2 commits
  6. 19 Apr, 2013 1 commit
  7. 17 Apr, 2013 2 commits
  8. 16 Apr, 2013 3 commits
  9. 14 Apr, 2013 3 commits
  10. 12 Apr, 2013 1 commit
  11. 11 Apr, 2013 1 commit
  12. 10 Apr, 2013 1 commit
  13. 09 Apr, 2013 12 commits
  14. 08 Apr, 2013 2 commits
    • Trond Myklebust's avatar
      NFSv4: Handle timeouts correctly when probing for lease validity · bc7a05ca
      Trond Myklebust authored
      When we send a RENEW or SEQUENCE operation in order to probe if the
      lease is still valid, we want it to be able to time out since the
      lease we are probing is likely to time out too. Currently, because
      we use soft mount semantics for these RPC calls, the return value
      is EIO, which causes the state manager to exit with an "unhandled
      error" message.
      This patch changes the call semantics, so that the RPC layer returns
      ETIMEDOUT instead of EIO. We then have the state manager default to
      a simple retry instead of exiting.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      bc7a05ca
    • J. Bruce Fields's avatar
      nfsd4: cleanup handling of nfsv4.0 closed stateid's · 9411b1d4
      J. Bruce Fields authored
      Closed stateid's are kept around a little while to handle close replays
      in the 4.0 case.  So we stash them in the last-used stateid in the
      oo_last_closed_stateid field of the open owner.  We can free that in
      encode_seqid_op_tail once the seqid on the open owner is next
      incremented.  But we don't want to do that on the close itself; so we
      set NFS4_OO_PURGE_CLOSE flag set on the open owner, skip freeing it the
      first time through encode_seqid_op_tail, then when we see that flag set
      next time we free it.
      
      This is unnecessarily baroque.
      
      Instead, just move the logic that increments the seqid out of the xdr
      code and into the operation code itself.
      
      The justification given for the current placement is that we need to
      wait till the last minute to be sure we know whether the status is a
      sequence-id-mutating error or not, but examination of the code shows
      that can't actually happen.
      Reported-by: default avatarYanchuan Nian <ycnian@gmail.com>
      Tested-by: default avatarYanchuan Nian <ycnian@gmail.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9411b1d4
  15. 05 Apr, 2013 7 commits