pnfs: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done
authorBoaz Harrosh <bharrosh@panasas.com>
Wed, 22 Jan 2014 18:34:54 +0000 (20:34 +0200)
committerTrond Myklebust <trond.myklebust@primarydata.com>
Thu, 23 Jan 2014 01:10:49 +0000 (18:10 -0700)
commited7e5423014ad89720fcf315c0b73f2c5d0c7bd2
tree63d2a86b73ccd5bb2f5f447d3de8bdba03d07a71
parent471252cd8b34b0609973740b25dcd1ff01dc1889
pnfs: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done

An NFS4ERR_RECALLCONFLICT is returned by server from a GET_LAYOUT
only when a Server Sent a RECALL do to that GET_LAYOUT, or
the RECALL and GET_LAYOUT crossed on the wire.
In any way this means we want to wait at most until in-flight IO
is finished and the RECALL can be satisfied.

So a proper wait here is more like 1/10 of a second, not 15 seconds
like we have now. In case of a server bug we delay exponentially
longer on each retry.

Current code totally craps out performance of very large files on
most pnfs-objects layouts, because of how the map changes when the
file has grown into the next raid group.

[Stable: This will patch back to 3.9. If there are earlier still
 maintained trees, please tell me I'll send a patch]

CC: Stable Tree <stable@vger.kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
fs/nfs/nfs4proc.c