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

[Trond Myklebust <trondmy@hammerspace.com>]

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.

> 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