1. 03 12月, 2012 3 次提交
  2. 29 11月, 2012 1 次提交
  3. 15 11月, 2012 4 次提交
  4. 13 11月, 2012 6 次提交
  5. 11 11月, 2012 1 次提交
  6. 08 11月, 2012 5 次提交
  7. 02 10月, 2012 1 次提交
  8. 21 8月, 2012 2 次提交
  9. 28 7月, 2012 2 次提交
  10. 20 6月, 2012 1 次提交
    • C
      NFSD: TEST_STATEID should not return NFS4ERR_STALE_STATEID · 7df302f7
      Chuck Lever 提交于
      According to RFC 5661, the TEST_STATEID operation is not allowed to
      return NFS4ERR_STALE_STATEID.  In addition, RFC 5661 says:
      
      15.1.16.5.  NFS4ERR_STALE_STATEID (Error Code 10023)
      
         A stateid generated by an earlier server instance was used.  This
         error is moot in NFSv4.1 because all operations that take a stateid
         MUST be preceded by the SEQUENCE operation, and the earlier server
         instance is detected by the session infrastructure that supports
         SEQUENCE.
      
      I triggered NFS4ERR_STALE_STATEID while testing the Linux client's
      NOGRACE recovery.  Bruce suggested an additional test that could be
      useful to client developers.
      
      Lastly, RFC 5661, section 18.48.3 has this:
      
       o  Special stateids are always considered invalid (they result in the
          error code NFS4ERR_BAD_STATEID).
      
      An explicit check is made for those state IDs to avoid printk noise.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7df302f7
  11. 01 6月, 2012 1 次提交
  12. 26 3月, 2012 2 次提交
    • J
      nfsd: add nfsd4_client_tracking_ops struct and a way to set it · 2a4317c5
      Jeff Layton 提交于
      Abstract out the mechanism that we use to track clients into a set of
      client name tracking functions.
      
      This gives us a mechanism to plug in a new set of client tracking
      functions without disturbing the callers. It also gives us a way to
      decide on what tracking scheme to use at runtime.
      
      For now, this just looks like pointless abstraction, but later we'll
      add a new alternate scheme for tracking clients on stable storage.
      
      Note too that this patch anticipates the eventual containerization
      of this code by passing in struct net pointers in places. No attempt
      is made to containerize the legacy client tracker however.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      2a4317c5
    • J
      nfsd: convert nfs4_client->cl_cb_flags to a generic flags field · a52d726b
      Jeff Layton 提交于
      We'll need a way to flag the nfs4_client as already being recorded on
      stable storage so that we don't continually upcall. Currently, that's
      recorded in the cl_firststate field of the client struct. Using an
      entire u32 to store a flag is rather wasteful though.
      
      The cl_cb_flags field is only using 2 bits right now, so repurpose that
      to a generic flags field. Rename NFSD4_CLIENT_KILL to
      NFSD4_CLIENT_CB_KILL to make it evident that it's part of the callback
      flags. Add a mask that we can use for existing checks that look to see
      whether any flags are set, so that the new flags don't interfere.
      
      Convert all references to cl_firstate to the NFSD4_CLIENT_STABLE flag,
      and add a new NFSD4_CLIENT_RECLAIM_COMPLETE flag.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a52d726b
  13. 07 3月, 2012 1 次提交
  14. 15 2月, 2012 2 次提交
  15. 06 1月, 2012 1 次提交
  16. 16 11月, 2011 1 次提交
    • J
      nfsd4: add a separate (lockowner, inode) lookup · 009673b4
      J. Bruce Fields 提交于
      Address the possible performance regression mentioned in "nfsd4: hash
      lockowners to simplify RELEASE_LOCKOWNER" by providing a separate
      (lockowner, inode) hash.
      
      Really, I doubt this matters much, but I think it's likely we'll change
      these data structures here and I'd rather that the need for (owner,
      inode) lookups be well-documented.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      009673b4
  17. 24 10月, 2011 1 次提交
  18. 18 10月, 2011 3 次提交
  19. 11 10月, 2011 2 次提交