1. 23 5月, 2012 6 次提交
    • C
      NFS: Add nfs_client behavior flags · 4bf590e0
      Chuck Lever 提交于
      "noresvport" and "discrtry" can be passed to nfs_create_rpc_client()
      by setting flags in the passed-in nfs_client.  This change makes it
      easy to add new flags.
      
      Note that these settings are now "sticky" over the lifetime of a
      struct nfs_client, and may even be copied when an nfs_client is
      cloned.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4bf590e0
    • C
      NFS: Always use the same SETCLIENTID boot verifier · f092075d
      Chuck Lever 提交于
      Currently our NFS client assigns a unique SETCLIENTID boot verifier
      for each server IP address it knows about.  It's set to CURRENT_TIME
      when the struct nfs_client for that server IP is created.
      
      During the SETCLIENTID operation, our client also presents an
      nfs_client_id4 string to servers, as an identifier on which the server
      can hang all of this client's NFSv4 state.  Our client's
      nfs_client_id4 string is unique for each server IP address.
      
      An NFSv4 server is obligated to wipe all NFSv4 state associated with
      an nfs_client_id4 string when the client presents the same
      nfs_client_id4 string along with a changed SETCLIENTID boot verifier.
      
      When our client unmounts the last of a server's shares, it destroys
      that server's struct nfs_client.  The next time the client mounts that
      NFS server, it creates a fresh struct nfs_client with a fresh boot
      verifier.  On seeing the fresh verifer, the server wipes any previous
      NFSv4 state associated with that nfs_client_id4.
      
      However, NFSv4.1 clients are supposed to present the same
      nfs_client_id4 string to all servers.  And, to support Transparent
      State Migration, the same nfs_client_id4 string should be presented
      to all NFSv4.0 servers so they recognize that migrated state for this
      client belongs with state a server may already have for this client.
      (This is known as the Uniform Client String model).
      
      If the nfs_client_id4 string is the same but the boot verifier changes
      for each server IP address, SETCLIENTID and EXCHANGE_ID operations
      from such a client could unintentionally result in a server wiping a
      client's previously obtained lease.
      
      Thus, if our NFS client is going to use a fixed nfs_client_id4 string,
      either for NFSv4.0 or NFSv4.1 mounts, our NFS client should use a
      boot verifier that does not change depending on server IP address.
      Replace our current per-nfs_client boot verifier with a per-nfs_net
      boot verifier.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f092075d
    • C
      NFS: Use proper naming conventions for the nfs_client.net field · 73ea666c
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Introduced by commit e50a7a1a "NFS: make NFS client allocated per
      network namespace context," Tue Jan 10, 2012.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      73ea666c
    • C
      NFS: Use proper naming conventions for nfs_client.impl_id field · 59155546
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Additionally, for consistency, move the impl_id field into the NFSv4-
      specific part of the nfs_client, and free that memory in the logic
      that shuts down NFSv4 nfs_clients.
      
      Introduced by commit 7d2ed9ac "NFSv4: parse and display server
      implementation ids," Fri Feb 17, 2012.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      59155546
    • C
      NFS: Use proper naming conventions for NFSv4.1 server scope fields · 79d4e1f0
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Additionally, for consistency, move the scope field into the NFSv4-
      specific part of the nfs_client, and free that memory in the logic
      that shuts down NFSv4 nfs_clients.
      
      Introduced by commit 99fe60d0 "nfs41: exchange_id operation", April
      1 2009.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      79d4e1f0
    • C
  2. 03 3月, 2012 1 次提交
  3. 02 3月, 2012 1 次提交
  4. 15 2月, 2012 2 次提交
  5. 07 2月, 2012 1 次提交
  6. 01 2月, 2012 3 次提交
  7. 06 1月, 2012 1 次提交
    • C
      NFS: Cache state owners after files are closed · 0aaaf5c4
      Chuck Lever 提交于
      Servers have a finite amount of memory to store NFSv4 open and lock
      owners.  Moreover, servers may have a difficult time determining when
      they can reap their state owner table, thanks to gray areas in the
      NFSv4 protocol specification.  Thus clients should be careful to reuse
      state owners when possible.
      
      Currently Linux is not too careful.  When a user has closed all her
      files on one mount point, the state owner's reference count goes to
      zero, and it is released.  The next OPEN allocates a new one.  A
      workload that serially opens and closes files can run through a large
      number of open owners this way.
      
      When a state owner's reference count goes to zero, slap it onto a free
      list for that nfs_server, with an expiry time.  Garbage collect before
      looking for a state owner.  This makes state owners for active users
      available for re-use.
      
      Now that there can be unused state owners remaining at umount time,
      purge the state owner free list when a server is destroyed.  Also be
      sure not to reclaim unused state owners during state recovery.
      
      This change has benefits for the client as well.  For some workloads,
      this approach drops the number of OPEN_CONFIRM calls from the same as
      the number of OPEN calls, down to just one.  This reduces wire traffic
      and thus open(2) latency.  Before this patch, untarring a kernel
      source tarball shows the OPEN_CONFIRM call counter steadily increasing
      through the test.  With the patch, the OPEN_CONFIRM count remains at 1
      throughout the entire untar.
      
      As long as the expiry time is kept short, I don't think garbage
      collection should be terribly expensive, although it does bounce the
      clp->cl_lock around a bit.
      
      [ At some point we should rationalize the use of the nfs_server
      ->destroy method. ]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      [Trond: Fixed a garbage collection race and a few efficiency issues]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0aaaf5c4
  8. 01 8月, 2011 3 次提交
  9. 27 7月, 2011 1 次提交
  10. 13 7月, 2011 2 次提交
  11. 25 4月, 2011 1 次提交
  12. 12 3月, 2011 5 次提交
  13. 11 3月, 2011 1 次提交
  14. 07 1月, 2011 5 次提交
  15. 25 10月, 2010 4 次提交
  16. 23 6月, 2010 1 次提交
  17. 15 5月, 2010 1 次提交
  18. 12 4月, 2010 1 次提交
    • T
      NFSv4: fix delegated locking · 0df5dd4a
      Trond Myklebust 提交于
      Arnaud Giersch reports that NFSv4 locking is broken when we hold a
      delegation since commit 8e469ebd (NFSv4:
      Don't allow posix locking against servers that don't support it).
      
      According to Arnaud, the lock succeeds the first time he opens the file
      (since we cannot do a delegated open) but then fails after we start using
      delegated opens.
      
      The following patch fixes it by ensuring that locking behaviour is
      governed by a per-filesystem capability flag that is initially set, but
      gets cleared if the server ever returns an OPEN without the
      NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set.
      Reported-by: NArnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      0df5dd4a