← NAS: shares, permissions, and operations
04 / 6 · 40 MIN

Caching, timeouts, and uncertainty

Interpret NFS options without confusing responsiveness, coherence, and remote outcome.

Concept and mechanism

Behavior during failure is part of the application contract. In Linux NFS, hard can keep requests waiting and retrying, while soft or softerr return errors under configured conditions. The manual warns of silent corruption in some soft cases; it is not a universal fix for a hung batch. timeo uses tenths of a second: 600 corresponds to sixty seconds for that timeout value without becoming a global deadline for the entire operation. Retries and other recovery phases can extend waiting. An application timeout also does not establish that a remote write was cancelled.

Guided application

Caching requires the same care with scope. noac addresses attribute caching and does not remove every data cache or coordination need. It can increase network operations and cost, so measure the change under comparable workload. Effective negotiated rsize and wsize can differ from requested configuration values. Use running mount state in analysis. In a fictional scenario, rename returns an error after server failure, but the name may already have changed before the failure. Reconcile file identity and consumer state before retrying. Missing acknowledgement proves neither absence of effect nor exactly-once processing.

IN PRACTICE

timeo=600 corresponds to 60 seconds in that unit; it is not the maximum duration of the whole flow.

Common pitfalls

soft as universal fix; noac as no caching at all; requested as negotiated value; error as absent effect.

Related topics: Shares and mounting · Identity and permissions · Security and write acknowledgement

Take this idea with you

Measure actual conditions and reconcile uncertain outcomes before repeating operations.

Create account

Reference: Linux NFS client options, cache and security · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior