> On Nov 26, 2020, at 8:48 AM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
>
> 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.
Indeed. Is there a reason to allow administrators to set these values?
>> 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
--
Chuck Lever
