1. 05 9月, 2013 4 次提交
    • T
      NFSv4: Document the recover_lost_locks kernel parameter · f6de7a39
      Trond Myklebust 提交于
      Rename the new 'recover_locks' kernel parameter to 'recover_lost_locks'
      and change the default to 'false'. Document why in
      Documentation/kernel-parameters.txt
      
      Move the 'recover_lost_locks' kernel parameter to fs/nfs/super.c to
      make it easy to backport to kernels prior to 3.6.x, which don't have
      a separate NFSv4 module.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f6de7a39
    • N
      NFSv4: Don't try to recover NFSv4 locks when they are lost. · ef1820f9
      NeilBrown 提交于
      When an NFSv4 client loses contact with the server it can lose any
      locks that it holds.
      
      Currently when it reconnects to the server it simply tries to reclaim
      those locks.  This might succeed even though some other client has
      held and released a lock in the mean time.  So the first client might
      think the file is unchanged, but it isn't.  This isn't good.
      
      If, when recovery happens, the locks cannot be claimed because some
      other client still holds the lock, then we get a message in the kernel
      logs, but the client can still write.  So two clients can both think
      they have a lock and can both write at the same time.  This is equally
      not good.
      
      There was a patch a while ago
        http://comments.gmane.org/gmane.linux.nfs/41917
      
      which tried to address some of this, but it didn't seem to go
      anywhere.  That patch would also send a signal to the process.  That
      might be useful but for now this patch just causes writes to fail.
      
      For NFSv4 (unlike v2/v3) there is a strong link between the lock and
      the write request so we can fairly easily fail any IO of the lock is
      gone.  While some applications might not expect this, it is still
      safer than allowing the write to succeed.
      
      Because this is a fairly big change in behaviour a module parameter,
      "recover_locks", is introduced which defaults to true (the current
      behaviour) but can be set to "false" to tell the client not to try to
      recover things that were lost.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ef1820f9
    • C
      NFS: Fix warning introduced by NFSv4.0 transport blocking patches · b6a85258
      Chuck Lever 提交于
      When CONFIG_NFS_V4_1 is not enabled, gcc emits this warning:
      
      linux/fs/nfs/nfs4state.c:255:12: warning:
       ‘nfs4_begin_drain_session’ defined but not used [-Wunused-function]
       static int nfs4_begin_drain_session(struct nfs_client *clp)
                  ^
      
      Eventually NFSv4.0 migration recovery will invoke this function, but
      that has not yet been merged.  Hide nfs4_begin_drain_session()
      behind CONFIG_NFS_V4_1 for now.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b6a85258
    • C
      When CONFIG_NFS_V4_1 is not enabled, "make C=2" emits this warning: · 1cec16ab
      Chuck Lever 提交于
      linux/fs/nfs/nfs4session.c:337:6: warning:
       symbol 'nfs41_set_target_slotid' was not declared. Should it be static?
      
      Move nfs41_set_target_slotid() and nfs41_update_target_slotid() back
      behind CONFIG_NFS_V4_1, since, in the final revision of this work,
      they are used only in NFSv4.1 and later.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1cec16ab
  2. 04 9月, 2013 18 次提交
  3. 01 9月, 2013 1 次提交
  4. 30 8月, 2013 3 次提交
  5. 23 8月, 2013 1 次提交
    • N
      NFS: remove incorrect "Lock reclaim failed!" warning. · 6686390b
      NeilBrown 提交于
      After reclaiming state that was lost, the NFS client tries to reclaim
      any locks, and then checks that each one has NFS_LOCK_INITIALIZED set
      (which means that the server has confirmed the lock).
      However if the client holds a delegation, nfs_reclaim_locks() simply aborts
      (or more accurately it called nfs_lock_reclaim() and that returns without
      doing anything).
      
      This is because when a delegation is held, the server doesn't need to
      know about locks.
      
      So if a delegation is held, NFS_LOCK_INITIALIZED is not expected, and
      its absence is certainly not an error.
      
      So don't print the warnings if NFS_DELGATED_STATE is set.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6686390b
  6. 22 8月, 2013 13 次提交