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. 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. -- Chuck Lever
