Unfortunately the application don't get notified when the reclaim failed.
Now you are making sure that application will fail because if they missed
the reclaim window they will not get the lock back and the application
will continue to run without a lock. Not sure this is better behavior.
Marc.
linux-nfs-owner@xxxxxxxxxxxxxxx wrote on 09/29/2008 07:44:03 PM:
>
> [PATCH 3/3] lockd: reject reclaims outside the grace period
>
> The current lockd does not reject reclaims that arrive outside of the
> grace period.
>
> Accepting a reclaim means promising to the client that no conflicting
> locks were granted since last it held the lock. We can meet that
> promise if we assume the only lockers are nfs clients, and that they are
> sufficiently well-behaved to reclaim only locks that they held before,
> and that only reclaim locks have been permitted so far. Once we leave
> the grace period (and start permitting non-reclaims), we can no longer
> keep that promise. So we must start rejecting reclaims at that point.
>
> Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>
> ---
> fs/lockd/svclock.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
> index 808d246..6063a8e 100644
> --- a/fs/lockd/svclock.c
> +++ b/fs/lockd/svclock.c
> @@ -410,6 +410,10 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct
> nlm_file *file,
> ret = nlm_lck_denied_grace_period;
> goto out;
> }
> + if (reclaim && !locks_in_grace()) {
> + ret = nlm_lck_denied_grace_period;
> + goto out;
> + }
>
> if (!wait)
> lock->fl.fl_flags &= ~FL_SLEEP;
> --
> 1.5.5.rc1
>
> --
> 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
--
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
