On Thu, 2020-11-26 at 12:47 +0200, Dan Aloni wrote:
> 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
Sorry, but those are completely silly timeo and retrans values for a
TCP connection. I see no reason why we should try to support them.
>
> 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/
>
Yes. If you artificially create congestion by telling the client to
keep resending all your outstanding data every 5 seconds, then it is
trivial to set up this kind of situation. That has always been the
case, and the patch you point to has nothing to do with this.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
