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;
Date:   Wed, 28 Aug 2019 10:48:39 -0400
From:   Bruce Fields <bfields@fieldses.org>
To:     "J. Bruce Fields" <bfields@redhat.com>
Cc:     Jeff Layton <jlayton@redhat.com>,
        Chuck Lever <chuck.lever@oracle.com>,
        Trond Myklebust <trondmy@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd
Message-ID: <20190828144839.GA26284@fieldses.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190828144031.GB14249@parsley.fieldses.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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?

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.