1. 07 12月, 2009 2 次提交
  2. 06 12月, 2009 19 次提交
  3. 05 12月, 2009 12 次提交
  4. 04 12月, 2009 7 次提交
    • N
      NFS4ERR_FILE_OPEN handling in Linux/NFS · 44ed3556
      NeilBrown 提交于
      NFS4ERR_FILE_OPEN is return by the server when an operation cannot be
      performed because the file is currently open and local (to the server)
      semantics prohibit the operation while the file is open.
      A typical case is a RENAME operation on an MS-Windows platform, which
      prevents rename while the file is open.
      
      While it is possible that such a condition is transitory, it is also
      very possible that the file will be held open for an extended period
      of time thus preventing the operation.
      
      The current behaviour of Linux/NFS is to retry the operation
      indefinitely.  This is not appropriate - we do not expect a rename to
      take an arbitrary amount of time to complete.
      
      Rather, and error should be returned.  The most obvious error code
      would be EBUSY, which is a legal at least for 'rename' and 'unlink',
      and accurately captures the reason for the error.
      
      This patch allows a few retries until about 2 seconds have elapsed,
      then returns EBUSY.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      44ed3556
    • M
      nfs: clean up sillyrenaming in nfs_rename() · 24e93025
      Miklos Szeredi 提交于
      The d_instantiate(new_dentry, NULL) is superfluous, the dentry is
      already negative.  Rehashing this dummy dentry isn't needed either,
      d_move() works fine on an unhashed target.
      
      The re-checking for busy after a failed nfs_sillyrename() is bogus
      too: new_dentry->d_count < 2 would be a bug here.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      24e93025
    • M
      nfs: dont unhash target if renaming a directory · 27226104
      Miklos Szeredi 提交于
      Move unhashing the target to after the check for existence and being a
      non-directory.
      
      If renaming a directory then the VFS already unhashes the target if it
      is not busy.  If it's busy then acquiring more references during the
      rename makes no difference.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      27226104
    • M
      nfs: fix comments in nfs_rename() · 28f79a1a
      Miklos Szeredi 提交于
      Comments are wrong or out of date.  In particular d_drop() doesn't
      free the inode it just unhashes the dentry.  And if target is a
      directory then it is not checked for being busy.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      28f79a1a
    • M
      nfs: remove unnecessary check from nfs_rename() · e48de5ec
      Miklos Szeredi 提交于
      VFS already checks if both source and target are directories.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e48de5ec
    • T
    • C
      NFS: Revert default r/wsize behavior · dd47f96c
      Chuck Lever 提交于
      When the "rsize=" or "wsize=" mount options are not specified,
      text-based mounts have slightly different behavior than legacy binary
      mounts.  Text-based mounts use the smaller of the server's maximum
      and the client's maximum, but binary mounts use the smaller of the
      server's _preferred_ size and the client's maximum.
      
      This difference is actually pretty subtle.  Most servers advertise
      the same value as their maximum and their preferred transfer size, so
      the end result is the same in most cases.
      
      The reason for this difference is that for text-based mounts, if
      r/wsize are not specified, they are set to the largest value supported
      by the client.  For legacy mounts, the values are set to zero if these
      options are not specified.
      
      nfs_server_set_fsinfo() can negotiate the transfer size defaults
      correctly in any case.  There's no need to specify any particular
      value as default in the text-based option parsing logic.
      
      Note that nfs4 doesn't use nfs_server_set_fsinfo(), but the mount.nfs4
      command does set rsize and wsize to 0 if the user didn't specify these
      options.  So, make the same change for text-based NFSv4 mounts.
      
      Thanks to James Pearson <james-p@moving-picture.com> for reporting and
      diagnosing the problem.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      dd47f96c