Do not multiply NFSv4.1 session concurrency by the connection count

Source facts

For NFSv4.1, Azure NetApp Files and the client negotiate a session request limit using the lower supported value. That session limit applies across its connections; extra connections do not each receive a fresh session allowance. Microsoft’s example with 64 session slots and two connections still permits 64 outstanding requests in total. Changes to the Linux max_session_slots setting require a reboot. Microsoft Learn.

Applicability

Use this check for Linux clients mounting Azure NetApp Files over NFSv4.1. Record the actual protocol, session-slot setting, and connection count; do not apply the source’s separate NFSv3 tuning model to this calculation.

DSE recommendation

Write down the desired outstanding-request budget before changing mount options. Distinguish session capacity from how that capacity is spread over network connections. Review the source’s server and per-connection limits alongside the measured workload, and schedule any required reboot through the client owner’s maintenance process. Avoid multiplying a session limit by the number of connections in a sizing spreadsheet.

Verification

Inspect the negotiated session information using the documented mount-trace approach, then measure the intended workload before and after a controlled change. Compare outstanding requests and latency rather than promising a throughput increase from a setting alone. Keep packet traces restricted and sanitize them for ordinary review. If the negotiated allowance is unchanged, investigate that fact before increasing concurrency elsewhere.

Official references

Microsoft Learn: Linux concurrency best practices for Azure NetApp Files – Session slots and slot table entries.