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;
Date:   Thu, 26 Nov 2020 12:47:12 +0200
From:   Dan Aloni <dan@kernelim.com>
To:     Scott Mayhew <smayhew@redhat.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Cc:     linux-nfs@vger.kernel.org
Subject: NFS v3 soft mount semantics affected by commit ce368536d
Message-ID: <20201126104712.GA4023536@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

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@hammerspace.com/

-- 
Dan Aloni