On 2/16/24 6:17 PM, Chuck Lever wrote:
On Sat, Feb 17, 2024 at 12:34:45AM +0100, Dan Shelton wrote:
On Thu, 15 Feb 2024 at 23:11, Dai Ngo <dai.ngo@xxxxxxxxxx> wrote:
Currently GETATTR conflict with a write delegation is handled by
recalling the delegation before replying to the GETATTR.
This patch series add supports for CB_GETATTR callback to get the latest
change_info and size information of the file from the client that holds
the delegation to reply to the GETATTR from the second client.
NOTE: this patch series is mostly the same as the previous patches which
were backed out when un unrelated problem of NFSD server hang on reboot
was reported.
The only difference is the wait_on_bit() in nfsd4_deleg_getattr_conflict was
replaced with wait_on_bit_timeout() with 30ms timeout to avoid a potential
DOS attack by exhausting NFSD kernel threads with GETATTR conflicts.
I have a concern about this static and very tiny timeout.
What will happen if the ICMPv6 latency is well over 30ms, like 660ms
(average 250mbit/s satellite latency)?
CB_GETATTR is an optimization for write delegation. Without
CB_GETATTR, or if the client does not respond within 30ms, the
server recalls the delegation. We expect no impact on clients
that connect on a high bandwidth-latency product link.
To lengthen that timeout would require the implementation of a
mechanism for NFSD to defer requests without tying up an NFSD
thread. So for the moment, the proposed CB_GETATTR implementation
will help fast local clients but should not negatively impact
remote clients, and we cannot in good faith provide a tunable
to extend that timeout beyond a few dozen milliseconds.
Would that not ruin delegations?
As stated above, it should not impact write delegation, and Dai can
correct me if I'm wrong, but I believe CB_GETATTR is not used if the
server has offered a read delegation.
Yes, CB_GETATTR is only used for write delegation.
NFSD implemented only read
delegation until very recently.
IIRC, there is instrumentation in v6.6 or v6.7's NFSD to measure
how often a CB_GETATTR might have been beneficial. I can provide
more detail when I'm in front of my desktop computer.
# cat /proc/net/rpc/nfsd |grep wdele
-Dai
