1. 24 Oct, 2010 1 commit
  2. 23 Oct, 2010 18 commits
  3. 19 Oct, 2010 4 commits
  4. 07 Oct, 2010 1 commit
    • Bryan Schumaker's avatar
      NFS: new idmapper · 955a857e
      Bryan Schumaker authored
      This patch creates a new idmapper system that uses the request-key function to
      place a call into userspace to map user and group ids to names.  The old
      idmapper was single threaded, which prevented more than one request from running
      at a single time.  This means that a user would have to wait for an upcall to
      finish before accessing a cached result.
      
      The upcall result is stored on a keyring of type id_resolver.  See the file
      Documentation/filesystems/nfs/idmapper.txt for instructions.
      Signed-off-by: default avatarBryan Schumaker <bjschuma@netapp.com>
      [Trond: fix up the return value of nfs_idmap_lookup_name and clean up code]
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      955a857e
  5. 29 Sep, 2010 3 commits
  6. 24 Sep, 2010 1 commit
  7. 23 Sep, 2010 3 commits
    • Suresh Jayaraman's avatar
      nfs: show "local_lock" mount option in /proc/mounts · 7c563cc9
      Suresh Jayaraman authored
      Display the status of 'local_lock' mount option in /proc/mounts.
      Signed-off-by: default avatarSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7c563cc9
    • Benny Halevy's avatar
      NFS: handle inode==NULL in __put_nfs_open_context · ef84303e
      Benny Halevy authored
      inode may be NULL when put_nfs_open_context is called from nfs_atomic_lookup
      before d_add_unique(dentry, inode)
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      ef84303e
    • Suresh Jayaraman's avatar
      nfs: introduce mount option '-olocal_lock' to make locks local · 5eebde23
      Suresh Jayaraman authored
      NFS clients since 2.6.12 support flock locks by emulating fcntl byte-range
      locks. Due to this, some windows applications which seem to use both flock
      (share mode lock mapped as flock by Samba) and fcntl locks sequentially on
      the same file, can't lock as they falsely assume the file is already locked.
      The problem was reported on a setup with windows clients accessing excel files
      on a Samba exported share which is originally a NFS mount from a NetApp filer.
      
      Older NFS clients (< 2.6.12) did not see this problem as flock locks were
      considered local. To support legacy flock behavior, this patch adds a mount
      option "-olocal_lock=" which can take the following values:
      
         'none'  		- Neither flock locks nor POSIX locks are local
         'flock' 		- flock locks are local
         'posix' 		- fcntl/POSIX locks are local
         'all'		- Both flock locks and POSIX locks are local
      
      Testing:
      
         - This patch was tested by using -olocal_lock option with different values
           and the NLM calls were noted from the network packet captured.
      
           'none'  - NLM calls were seen during both flock() and fcntl(), flock lock
         	       was granted, fcntl was denied
           'flock' - no NLM calls for flock(), NLM call was seen for fcntl(),
         	       granted
           'posix' - NLM call was seen for flock() - granted, no NLM call for fcntl()
           'all'   - no NLM calls were seen during both flock() and fcntl()
      
         - No bugs were seen during NFSv4 locking/unlocking in general and NFSv4
           reboot recovery.
      
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: default avatarSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      5eebde23
  8. 22 Sep, 2010 1 commit
  9. 21 Sep, 2010 7 commits
  10. 17 Sep, 2010 1 commit
    • Jeff Layton's avatar
      nfs: make sillyrename an async operation · d3d4152a
      Jeff Layton authored
      A synchronous rename can be interrupted by a SIGKILL. If that happens
      during a sillyrename operation, it's possible for the rename call to
      be sent to the server, but the task exits before processing the
      reply. If this happens, the sillyrenamed file won't get cleaned up
      during nfs_dentry_iput and the server is left with a dangling .nfs* file
      hanging around.
      
      Fix this problem by turning sillyrename into an asynchronous operation
      and have the task doing the sillyrename just wait on the reply. If the
      task is killed before the sillyrename completes, it'll still proceed
      to completion.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d3d4152a