Project

General

Profile

Actions

Bug #4837

open

NFSv4 client lock retry delay upper limit should be shorter

Added by Marcel Telka over 8 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2014-05-02
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

In a case the NFSv4 client cannot get a lock, the exponential backoff is implemented in nfs4_block_and_wait(). The upper limit of the delay is the lease_time of the NFSv4 server. According to the RFC 3530, chapter 8.4. Blocking Locks, to maintain fairness of the locking the client should retry to acquire lock faster than the lease period (lease_time).

With the current implementation (when the upper limit of the backoff time is lease_time), it might happen that the client is not fast enough and the server might grant the lock to some other client, causing our client to starve (possible for very long time).

To avoid this, the upper limit of backoff should be smaller than lease_time. I suggest to use similar calculation of the upper limit as it is used for the renew period - see nfs4_renew_lease_thread() for details. The renew period is roughly half of the lease_time.


Related issues

Related to illumos gate - Bug #4827: nfs4: slow file lockingNew2014-04-30

Actions
Related to illumos gate - Bug #4842: NFSv4 locking implementation at server is unfairNew2014-05-03

Actions
Actions #1

Updated by Marcel Telka over 8 years ago

  • Subject changed from NFSv4 client to NFSv4 client lock retry delay should be shorter
Actions #2

Updated by Marcel Telka over 8 years ago

  • Subject changed from NFSv4 client lock retry delay should be shorter to NFSv4 client lock retry delay upper limit should be shorter
Actions

Also available in: Atom PDF