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