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: <20190828144839.GA26284@fieldses.org>
Date:   Wed, 28 Aug 2019 10:50:30 -0400
Cc:     Bruce Fields <bfields@redhat.com>,
        Jeff Layton <jlayton@redhat.com>,
        Trond Myklebust <trondmy@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: 7bit
Message-Id: <AAF793DB-25B7-42A5-9795-5317B5052F44@oracle.com>
References: <20190827145819.GB9804@fieldses.org>
 <20190827145912.GC9804@fieldses.org>
 <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com>
 <20190828134839.GA26492@fieldses.org>
 <ed2a86da204cbf644ef2dada4bda2b899da48764.camel@redhat.com>
 <45582F32-69C7-4DC8-A608-E45038A44D42@oracle.com>
 <20190828140044.GA14249@parsley.fieldses.org>
 <990B7B57-53B8-4ECB-A08B-1AFD2FCE13A6@oracle.com>
 <31658faabfbe3b4c2925bd899e264adf501fbc75.camel@redhat.com>
 <20190828144031.GB14249@parsley.fieldses.org>
 <20190828144839.GA26284@fieldses.org>
To:     Bruce Fields <bfields@fieldses.org>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Aug 28, 2019, at 10:48 AM, Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Wed, Aug 28, 2019 at 10:40:31AM -0400, J. Bruce Fields wrote:
>> On Wed, Aug 28, 2019 at 10:16:09AM -0400, Jeff Layton wrote:
>>> For the most part, these sorts of errors tend to be rare. If it turns
>>> out to be a problem we could consider moving the verifier into
>>> svc_export or something?
>> 
>> As Trond says, this isn't really a server implementation issue, it's a
>> protocol issue.  If a client detects when to resend writes by storing a
>> single verifier per server, then returning different verifiers from
>> writes to different exports will have it resending every time it writes
>> to one export then another.
> 
> The other way to limit this is by trying to detect the single-writer
> case, since it's probably also rare for multiple clients to write to the
> same file.
> 
> Are there any common cases where two clients share the same TCP
> connection?  Maybe that would be a conservative enough test?

What happens if a client reconnects? Does that bump the verifier?

If it reconnects from the same source port, can the server tell
that the connection is different?


> And you wouldn't have to track every connection that's ever sent a WRITE
> to a given file.  Just remember the first one, with a flag to track
> whether anyone else has ever written to it.
> 
> ??
> 
> --b.

--
Chuck Lever