1. 23 Jun, 2006 1 commit
  2. 11 Apr, 2006 3 commits
  3. 24 Mar, 2006 1 commit
  4. 19 Jan, 2006 2 commits
  5. 07 Nov, 2005 1 commit
  6. 08 Jul, 2005 3 commits
    • NeilBrown's avatar
      [PATCH] nfsd4: fix fh_expire_type · e34ac862
      NeilBrown authored
      
      
      After discussion at the recent NFSv4 bake-a-thon, I realized that my
      assumption that NFS4_FH_PERSISTENT required filehandles to persist was a
      misreading of the spec.  This also fixes an interoperability problem with the
      Solaris client.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e34ac862
    • NeilBrown's avatar
      [PATCH] nfsd4: seqid comments · 7fb64cee
      NeilBrown authored
      
      
      Add some comments on the use of so_seqid, in an attempt to avoid some of the
      confusion outlined in the previous patch....
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7fb64cee
    • NeilBrown's avatar
      [PATCH] nfsd4: fix open_reclaim seqid · bd9aac52
      NeilBrown authored
      
      
      The sequence number we store in the sequence id is the last one we received
      from the client.  So on the next operation we'll check that the client gives
      us the next higher number.
      
      We increment sequence id's at the last moment, in encode, so that we're sure
      of knowing the right error return.  (The decision to increment the sequence id
      depends on the exact error returned.)
      
      However on the *first* use of a sequence number, if we set the sequence number
      to the one received from the client and then let the increment happen on
      encode, we'll be left with a sequence number one to high.
      
      For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on
      *confirmed* stateowners.
      
      This creates a problem for open reclaims, which are confirmed on first use.
      Therefore the open reclaim code, as a special exception, *decrements* the
      sequence id, cancelling out the undesired increment on encode.  But this
      prevents the sequence id from ever being incremented in the case where
      multiple reclaims are sent with the same openowner.  Yuch!
      
      We could add another exception to the open reclaim code, decrementing the
      sequence id only if this is the first use of the open owner.
      
      But it's simpler by far to modify the meaning of the op_seqid field: instead
      of representing the previous value sent by the client, we take op_seqid, after
      encoding, to represent the *next* sequence id that we expect from the client.
      This eliminates the need for special-case handling of the first use of a
      stateowner.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bd9aac52
  7. 24 Jun, 2005 3 commits
  8. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4