diff options
author | NeilBrown <neilb@suse.de> | 2014-09-18 16:09:27 +1000 |
---|---|---|
committer | Trond Myklebust <trond.myklebust@primarydata.com> | 2014-09-24 23:22:47 -0400 |
commit | 8478eaa16e701ecfe054b62ec764bc1291b79e19 (patch) | |
tree | a9cfe8c31443d372d1fe7ac8ad876152be94026f /REPORTING-BUGS | |
parent | 3dedbb5ca10ef13f25055776d2f6d9499d9ca1ba (diff) | |
download | blackbird-op-linux-8478eaa16e701ecfe054b62ec764bc1291b79e19.tar.gz blackbird-op-linux-8478eaa16e701ecfe054b62ec764bc1291b79e19.zip |
NFSv4: use exponential retry on NFS4ERR_DELAY for async requests.
Currently asynchronous NFSv4 request will be retried with
exponential timeout (from 1/10 to 15 seconds), but async
requests will always use a 15second retry.
Some "async" requests are really synchronous though. The
async mechanism is used to allow the request to continue if
the requesting process is killed.
In those cases, an exponential retry is appropriate.
For example, if two different clients both open a file and
get a READ delegation, and one client then unlinks the file
(while still holding an open file descriptor), that unlink
will used the "silly-rename" handling which is async.
The first rename will result in NFS4ERR_DELAY while the
delegation is reclaimed from the other client. The rename
will not be retried for 15 seconds, causing an unlink to take
15 seconds rather than 100msec.
This patch only added exponential timeout for async unlink and
async rename. Other async calls, such as 'close' are sometimes
waited for so they might benefit from exponential timeout too.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to 'REPORTING-BUGS')
0 files changed, 0 insertions, 0 deletions