1. 09 6月, 2006 6 次提交
  2. 21 3月, 2006 2 次提交
    • T
      NFS: Cleanup of NFS read code · ec06c096
      Trond Myklebust 提交于
      Same callback hierarchy inversion as for the NFS write calls. This patch is
      not strictly speaking needed by the O_DIRECT code, but avoids confusing
      differences between the asynchronous read and write code.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ec06c096
    • T
      NFS: Cleanup of NFS write code in preparation for asynchronous o_direct · 788e7a89
      Trond Myklebust 提交于
      This patch inverts the callback hierarchy for NFS write calls.
      
      Instead of having the NFSv2/v3/v4-specific code set up the RPC callback
      ops, we allow the original caller to do so. This allows for more
      flexibility w.r.t. how to set up and tear down the nfs_write_data
      structure while still allowing the NFSv3/v4 code to perform error
      handling.
      
      The greater flexibility is needed by the asynchronous O_DIRECT code, which
      wants to be able to hold on to the original nfs_write_data structures after
      the WRITE RPC call has completed in order to be able to replay them if the
      COMMIT call determines that the server has rebooted.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      788e7a89
  3. 07 1月, 2006 4 次提交
  4. 28 10月, 2005 7 次提交
  5. 19 10月, 2005 5 次提交
    • T
      NFSv4: Eliminate nfsv4 open race... · 02a913a7
      Trond Myklebust 提交于
       Make NFSv4 return the fully initialized file pointer with the
       stateid that it created in the lookup w/intent.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      02a913a7
    • T
      06735b34
    • T
      NFSv4: Make NFS clean up byte range locks asynchronously · faf5f49c
      Trond Myklebust 提交于
       Currently we fail to do so if the process was signalled.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      faf5f49c
    • T
      NFSv4: Fix a potential CLOSE race · 9512135d
      Trond Myklebust 提交于
       Once the state_owner and lock_owner semaphores get removed, it will be
       possible for other OPEN requests to reopen the same file if they have
       lower sequence ids than our CLOSE call.
       This patch ensures that we recheck the file state once
       nfs_wait_on_sequence() has completed waiting.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      9512135d
    • T
      NFSv4: Add functions to order RPC calls · cee54fc9
      Trond Myklebust 提交于
       NFSv4 file state-changing functions such as OPEN, CLOSE, LOCK,... are all
       labelled with "sequence identifiers" in order to prevent the server from
       reordering RPC requests, as this could cause its file state to
       become out of sync with the client.
      
       Currently the NFS client code enforces this ordering locally using
       semaphores to restrict access to structures until the RPC call is done.
       This, of course, only works with synchronous RPC calls, since the
       user process must first grab the semaphore.
       By dropping semaphores, and instead teaching the RPC engine to hold
       the RPC calls until they are ready to be sent, we can extend this
       process to work nicely with asynchronous RPC calls too.
      
       This patch adds a new list called "rpc_sequence" that defines the order
       of the RPC calls to be sent. We add one such list for each state_owner.
       When an RPC call is ready to be sent, it checks if it is top of the
       rpc_sequence list. If so, it proceeds. If not, it goes back to sleep,
       and loops until it hits top of the list.
       Once the RPC call has completed, it can then bump the sequence id counter,
       and remove itself from the rpc_sequence list, and then wake up the next
       sleeper.
      
       Note that the state_owner sequence ids and lock_owner sequence ids are
       all indexed to the same rpc_sequence list, so OPEN, LOCK,... requests
       are all ordered w.r.t. each other.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      cee54fc9
  6. 23 6月, 2005 5 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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