Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com>
Date:   Tue, 27 Aug 2019 11:20:44 -0400
Cc:     Bruce Fields <bfields@fieldses.org>,
        Jeff Layton <jlayton@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Bruce Fields <bfields@redhat.com>,
        Jeff Layton <jlayton@poochiereds.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FDE5284-AD41-46B6-A257-DE9D5F24932D@oracle.com>
References: <20190826165021.81075-1-trond.myklebust@hammerspace.com>
 <20190826205156.GA27834@fieldses.org>
 <ef9f2791ef395d7c968a386ce0a32ea503d6478f.camel@hammerspace.com>
 <61F77AD6-BD02-4322-B944-0DC263EB9BD8@oracle.com>
 <ec7a06f8e74867e65c26580e8504e2879f4cd595.camel@hammerspace.com>
 <20190827145819.GB9804@fieldses.org> <20190827145912.GC9804@fieldses.org>
 <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Aug 27, 2019, at 11:15 AM, Trond Myklebust =
<trondmy@hammerspace.com> wrote:
>=20
> On Tue, 2019-08-27 at 10:59 -0400, bfields@fieldses.org wrote:
>> On Tue, Aug 27, 2019 at 10:58:19AM -0400, bfields@fieldses.org wrote:
>>> On Tue, Aug 27, 2019 at 02:53:01PM +0000, Trond Myklebust wrote:
>>>> The one problem is that the looping forever client can cause
>>>> other
>>>> clients to loop forever on their otherwise successful writes on
>>>> other
>>>> files.
>>>=20
>>> Yeah, that's the case I was wondering about.
>>>=20
>>>> That's bad, but again, that's due to client behaviour that is
>>>> toxic even today.
>>>=20
>>> So my worry was that if write errors are rare and the consequences
>>> of
>>> the single client looping forever are relatively mild, then there
>>> might
>>> be deployed clients that get away with that behavior.
>>>=20
>>> But maybe the behavior's a lot more "toxic" than I imagined, hence
>>> unlikely to be very common.
>>=20
>> (And, to be clear, I like the idea, just making sure I'm not
>> overlooking
>> any problems....)
>>=20
> I'm open to other suggestions, but I'm having trouble finding one that
> can scale correctly (i.e. not require per-client tracking), prevent
> silent corruption (by causing clients to miss errors), while not
> relying on optional features that may not be implemented by all NFSv3
> clients (e.g. per-file write verifiers are not implemented by *BSD).
>=20
> That said, it seems to me that to do nothing should not be an option,
> as that would imply tolerating silent corruption of file data.

Agree, we should move forward. I'm not saying "do nothing," I'm
just trying to understand what is improved and what is still left
to do (maybe nothing).


--
Chuck Lever