f16b6e8d83
The current practice of waiting for cache updates by queueing the whole request to be retried has (at least) two problems. 1/ With NFSv4, requests can be quite complex and re-trying a whole request when a later part fails should only be a last-resort, not a normal practice. 2/ Large requests, and in particular any 'write' request, will not be queued by the current code and doing so would be undesirable. In many cases only a very sort wait is needed before the cache gets valid data. So, providing the underlying transport permits it by setting ->thread_wait, arrange to wait briefly for an upcall to be completed (as reflected in the clearing of CACHE_PENDING). If the short wait was not long enough and CACHE_PENDING is still set, fall back on the old approach. The 'thread_wait' value is set to 5 seconds when there are spare threads, and 1 second when there are no spare threads. These values are probably much higher than needed, but will ensure some forward progress. Note that as we only request an update for a non-valid item, and as non-valid items are updated in place it is extremely unlikely that cache_check will return -ETIMEDOUT. Normally cache_defer_req will sleep for a short while and then find that the item is_valid. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> |
||
---|---|---|
.. | ||
auth_gss.h | ||
auth.h | ||
bc_xprt.h | ||
cache.h | ||
clnt.h | ||
debug.h | ||
gss_api.h | ||
gss_asn1.h | ||
gss_err.h | ||
gss_krb5.h | ||
gss_spkm3.h | ||
Kbuild | ||
metrics.h | ||
msg_prot.h | ||
rpc_pipe_fs.h | ||
rpc_rdma.h | ||
sched.h | ||
stats.h | ||
svc_rdma.h | ||
svc_xprt.h | ||
svc.h | ||
svcauth_gss.h | ||
svcauth.h | ||
svcsock.h | ||
timer.h | ||
types.h | ||
xdr.h | ||
xprt.h | ||
xprtrdma.h | ||
xprtsock.h |