1. 26 2月, 2013 1 次提交
    • J
      vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op · ecf3d1f1
      Jeff Layton 提交于
      The following set of operations on a NFS client and server will cause
      
          server# mkdir a
          client# cd a
          server# mv a a.bak
          client# sleep 30  # (or whatever the dir attrcache timeout is)
          client# stat .
          stat: cannot stat `.': Stale NFS file handle
      
      Obviously, we should not be getting an ESTALE error back there since the
      inode still exists on the server. The problem is that the lookup code
      will call d_revalidate on the dentry that "." refers to, because NFS has
      FS_REVAL_DOT set.
      
      nfs_lookup_revalidate will see that the parent directory has changed and
      will try to reverify the dentry by redoing a LOOKUP. That of course
      fails, so the lookup code returns ESTALE.
      
      The problem here is that d_revalidate is really a bad fit for this case.
      What we really want to know at this point is whether the inode is still
      good or not, but we don't really care what name it goes by or whether
      the dcache is still valid.
      
      Add a new d_op->d_weak_revalidate operation and have complete_walk call
      that instead of d_revalidate. The intent there is to allow for a
      "weaker" d_revalidate that just checks to see whether the inode is still
      good. This is also gives us an opportunity to kill off the FS_REVAL_DOT
      special casing.
      
      [AV: changed method name, added note in porting, fixed confusion re
      having it possibly called from RCU mode (it won't be)]
      
      Cc: NeilBrown <neilb@suse.de>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ecf3d1f1
  2. 05 2月, 2013 1 次提交
  3. 01 2月, 2013 1 次提交
  4. 28 1月, 2013 1 次提交
  5. 04 1月, 2013 1 次提交
  6. 22 12月, 2012 1 次提交
  7. 15 12月, 2012 1 次提交
  8. 06 12月, 2012 1 次提交
  9. 01 11月, 2012 2 次提交
  10. 02 10月, 2012 4 次提交
    • S
      nfs: declare nfs_xdev_mount as static · 3dd4f8ef
      Stanislav Kinsbursky 提交于
      Sparse warning:
      fs/nfs/super.c:2517:15: warning: symbol 'nfs_xdev_mount' was not declared.
      Should it be static?
      Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3dd4f8ef
    • D
      nfs: replace strict_strto* with kstrto* · 7297cb68
      Daniel Walter 提交于
      [nfs] replace strict_str* with kstr* variants
      
       * replace string conversions with newer kstr* functions
      Signed-off-by: NDaniel Walter <sahne@0x90.at>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      7297cb68
    • C
      NFS: Add nfs4_unique_id boot parameter · 6f2ea7f2
      Chuck Lever 提交于
      An optional boot parameter is introduced to allow client
      administrators to specify a string that the Linux NFS client can
      insert into its nfs_client_id4 id string, to make it both more
      globally unique, and to ensure that it doesn't change even if the
      client's nodename changes.
      
      If this boot parameter is not specified, the client's nodename is
      used, as before.
      
      Client installation procedures can create a unique string (typically,
      a UUID) which remains unchanged during the lifetime of that client
      instance.  This works just like creating a UUID for the label of the
      system's root and boot volumes.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6f2ea7f2
    • C
      NFS: Introduce "migration" mount option · 89652617
      Chuck Lever 提交于
      Currently, the Linux client uses a unique nfs_client_id4.id string
      when identifying itself to distinct NFS servers.
      
      To support transparent state migration, the Linux client will have to
      use the same nfs_client_id4 string for all servers it communicates
      with (also known as the "uniform client string" approach).  Otherwise
      NFS servers can not recognize that open and lock state need to be
      merged after a file system transition.
      
      Unfortunately, there are some NFSv4.0 servers currently in the field
      that do not tolerate the uniform client string approach.
      
      Thus, by default, our NFSv4.0 mounts will continue to use the current
      approach, and we introduce a mount option that switches them to use
      the uniform model.  Client administrators must identify which servers
      can be mounted with this option.  Eventually most NFSv4.0 servers will
      be able to handle the uniform approach, and we can change the default.
      
      The first mount of a server controls the behavior for all subsequent
      mounts for the lifetime of that set of mounts of that server.  After
      the last mount of that server is gone, the client erases the data
      structure that tracks the lease.  A subsequent lease may then honor
      a different "migration" setting.
      
      This patch adds only the infrastructure for parsing the new mount
      option.  Support for uniform client strings is added in a subsequent
      patch.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      89652617
  11. 05 9月, 2012 1 次提交
  12. 02 9月, 2012 1 次提交
  13. 17 8月, 2012 2 次提交
  14. 31 7月, 2012 9 次提交
  15. 18 7月, 2012 2 次提交
  16. 14 7月, 2012 1 次提交
  17. 11 7月, 2012 1 次提交
  18. 29 6月, 2012 2 次提交
  19. 10 6月, 2012 1 次提交
  20. 06 6月, 2012 1 次提交
  21. 23 5月, 2012 1 次提交
  22. 17 5月, 2012 1 次提交
  23. 15 5月, 2012 3 次提交