1. 27 1月, 2010 2 次提交
  2. 16 12月, 2009 2 次提交
  3. 07 12月, 2009 1 次提交
  4. 06 12月, 2009 4 次提交
  5. 05 12月, 2009 3 次提交
  6. 22 7月, 2009 1 次提交
    • T
      NFSv4: Fix an NFSv4 mount regression · fccba804
      Trond Myklebust 提交于
      Commit 008f55d0 (nfs41: recover lease in
      _nfs4_lookup_root) forces the state manager to always run on mount. This is
      a bug in the case of NFSv4.0, which doesn't require us to send a
      setclientid until we want to grab file state.
      
      In any case, this is completely the wrong place to be doing state
      management. Moving that code into nfs4_init_session...
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      fccba804
  7. 18 6月, 2009 10 次提交
  8. 28 3月, 2009 1 次提交
  9. 31 12月, 2008 1 次提交
  10. 24 12月, 2008 9 次提交
  11. 17 5月, 2008 1 次提交
  12. 11 1月, 2008 1 次提交
  13. 20 10月, 2007 2 次提交
  14. 20 7月, 2007 1 次提交
  15. 11 7月, 2007 1 次提交
    • T
      NFSv4: Make the NFS state model work with the nosharedcache mount option · 6f2e64d3
      Trond Myklebust 提交于
      Consider the case where the user has mounted the remote filesystem
      server:/foo on the two local directories /bar and /baz using the
      nosharedcache mount option. The files /bar/file and /baz/file are
      represented by different inodes in the local namespace, but refer to the
      same file /foo/file on the server.
      Consider the case where a process opens both /bar/file and /baz/file, then
      closes /bar/file: because the nfs4_state is not shared between /bar/file
      and /baz/file, the kernel will see that the nfs4_state for /bar/file is no
      longer referenced, so it will send off a CLOSE rpc call. Unless the
      open_owners differ, then that CLOSE call will invalidate the open state on
      /baz/file too.
      
      Conclusion: we cannot share open state owners between two different
      non-shared mount instances of the same filesystem.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6f2e64d3