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@xxxxxxxxxxxxxxx
