Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd

["bfields@fieldses.org" <bfields@fieldses.org>]

On Tue, Aug 27, 2019 at 02:59:34PM +0000, Trond Myklebust wrote:
> On Tue, 2019-08-27 at 10:54 -0400, Bruce Fields wrote:
> > On Tue, Aug 27, 2019 at 09:59:25AM -0400, Chuck Lever wrote:
> > > The strategy of handling these errors more carefully seems good.
> > > Bumping the write/commit verifier so the client writes again to
> > > retrieve the latent error is clever!
> > > 
> > > It's not clear to me though that the NFSv3 protocol can deal with
> > > the multi-client write scenario, since it is stateless. We are now
> > > making it stateful in some sense by preserving error state on the
> > > server across NFS requests, without having any sense of an open
> > > file in the protocol itself.
> > > 
> > > Would an "approximation" without open state be good enough?
> > 
> > I figure there's a correct-but-slow approach which is to increment
> > the
> > write verifier every time there's a write error.  Does that work?  If
> > write errors are rare enough, maybe it doesn't matter that that's
> > slow?
> 
> How is that different from changing the boot verifier?
> Are you
> proposing to track write verifiers on a per-client basis? That seems
> onerous too.

Sorry, I thought "write verifier" and "boot verifier" were synonyms,
and, no, wasn't suggesting tracking it per-file.

--b.

> > Then there's various approximations you could use (IP address?) to
> > guess
> > when only one client's accessing the file.  You save forcing all the
> > clients to resend writes at the expense of some complexity and
> > correctness--e.g., multiple clients behind NAT might not all get
> > write
> > errors.
> > 
> > Am I thinking aobut this right?
> 
> I agree that there are multiple problems with tracking on a per-client
> basis.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
> 
>