Hi Scott, Trond, Commit ce368536dd614452407dc31e2449eb84681a06af ("nfs: nfs_file_write() should check for writeback errors") seems to have affected NFS v3 soft mount behavior, causing applications to fail on a slow band connection with a properly functioning server. I checked this with recent Linux 5.10-rc5, and on 5.8.18 to where this commit is backported. Question: while the NFS v4 protocol talks about a soft mount timeout behavior at "RFC7530 section 3.1.1" (see reference and patchset addressing it in [1]), is it valid to assume that a similar guarantee for NFS v3 soft mounts is expected? The reason why it is important, is because the fulfilment of this guarantee seemed to have changed with this recent patch. Details on reproduction - using the following mount option: vers=3,rsize=1048576,wsize=1048576,soft,proto=tcp,timeo=50,retrans=16 This is done along with rate limiting on the outgoing interface: tc qdisc add dev eth0 root tbf rate 4000kbit latency 1ms burst 1540 And performing following parallel work on the mountpoint: for i in `seq 1 100` ; do (dd if=/dev/zero of=x$i &) ; done Result is that EIOs are returned to `dd`, whereas without this commit the IOs simply performed slowly, and no errors observed by dd. It appears in traces that the NFS layer is doing the retries. [1] https://patchwork.kernel.org/project/linux-nfs/cover/20190328205239.29674-1-trond.myklebust@xxxxxxxxxxxxxxx/ -- Dan Aloni