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;
Message-ID: <ed2a86da204cbf644ef2dada4bda2b899da48764.camel@redhat.com>
Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd
From:   Jeff Layton <jlayton@redhat.com>
To:     "bfields@fieldses.org" <bfields@fieldses.org>,
        Trond Myklebust <trondmy@hammerspace.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "bfields@redhat.com" <bfields@redhat.com>,
        "chuck.lever@oracle.com" <chuck.lever@oracle.com>
Date:   Wed, 28 Aug 2019 09:51:28 -0400
In-Reply-To: <20190828134839.GA26492@fieldses.org>
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>
         <20190828134839.GA26492@fieldses.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Wed, 2019-08-28 at 09:48 -0400, bfields@fieldses.org wrote:
> On Tue, Aug 27, 2019 at 03:15:35PM +0000, Trond Myklebust wrote:
> > 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).
> > 
> > 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.
> 
> So should we increment the boot verifier every time we discover an error
> on an asynchronous write?
> 

I think so. Otherwise, only one client will ever see that error.
-- 
Jeff Layton <jlayton@redhat.com>