Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: NFS v3 soft mount semantics affected by commit ce368536d
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <dc888c162b3a30cd1c617072ae606d9d8c6d42f3.camel@hammerspace.com>
Date:   Thu, 26 Nov 2020 12:21:18 -0500
Cc:     "dan@kernelim.com" <dan@kernelim.com>,
        "smayhew@redhat.com" <smayhew@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA32469D-6897-4444-898B-01E7530E2CE0@oracle.com>
References: <20201126104712.GA4023536@gmail.com>
 <dc888c162b3a30cd1c617072ae606d9d8c6d42f3.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Precedence: bulk


> On Nov 26, 2020, at 8:48 AM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Thu, 2020-11-26 at 12:47 +0200, Dan Aloni wrote:
>> Hi Scott, Trond,
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> The reason why it is important, is because the fulfilment of this
>> guarantee seemed to have changed with this recent patch.
>>=20
>> Details on reproduction - using the following mount option:
>>=20
>>   =20
>> vers=3D3,rsize=3D1048576,wsize=3D1048576,soft,proto=3Dtcp,timeo=3D50,re=
trans=3D16
>=20
> 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:
>>=20
>>     tc qdisc add dev eth0 root tbf rate 4000kbit latency 1ms burst
>> 1540
>>=20
>> And performing following parallel work on the mountpoint:
>>=20
>>     for i in `seq 1 100` ; do (dd if=3D/dev/zero of=3Dx$i &) ; done
>>=20
>> 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.
>>=20
>> [1] =20
>> =
https://patchwork.kernel.org/project/linux-nfs/cover/20190328205239.29674-=
1-trond.myklebust@hammerspace.com/
>>=20
>=20
> 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.
>=20
> --=20
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com

--
Chuck Lever