On Tue, Jul 21, 2015 at 08:44:44AM +0200, Frank Steiner wrote: > J. Bruce Fields wrote > > > One way to confirm that might be to run client kernels modified to make > > the polling behavior (controlled by > > fs/nfs/nfs4proc.c:nfs4_set_lock_task_retry()) more aggressive, and see > > if that removes the delays in your case. > > > > If that works, then it might also be worth considering implementing > > CB_NOTIFY_LOCK: > > > > https://tools.ietf.org/html/rfc5661#page-593 > > I wouldn't mind to test any kind of patch if someone would find the time > to provide some. Writing them myself is beyond my skills I'm afraid :-) Well, I was just thinking of something like this. (*Not* saying this is what we really want to do, but it might help confirm where your delay is coming from.) --b. diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 6f228b5..c119ba7 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -5367,7 +5367,7 @@ int nfs4_proc_delegreturn(struct inode *inode, struct rpc_cred *cred, const nfs4 return err; } -#define NFS4_LOCK_MINTIMEOUT (1 * HZ) +#define NFS4_LOCK_MINTIMEOUT (1 * HZ / 10) #define NFS4_LOCK_MAXTIMEOUT (30 * HZ) /* -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
