> On Aug 28, 2019, at 10:48 AM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Wed, Aug 28, 2019 at 10:40:31AM -0400, J. Bruce Fields wrote: >> On Wed, Aug 28, 2019 at 10:16:09AM -0400, Jeff Layton wrote: >>> For the most part, these sorts of errors tend to be rare. If it turns >>> out to be a problem we could consider moving the verifier into >>> svc_export or something? >> >> As Trond says, this isn't really a server implementation issue, it's a >> protocol issue. If a client detects when to resend writes by storing a >> single verifier per server, then returning different verifiers from >> writes to different exports will have it resending every time it writes >> to one export then another. > > The other way to limit this is by trying to detect the single-writer > case, since it's probably also rare for multiple clients to write to the > same file. > > Are there any common cases where two clients share the same TCP > connection? Maybe that would be a conservative enough test? What happens if a client reconnects? Does that bump the verifier? If it reconnects from the same source port, can the server tell that the connection is different? > And you wouldn't have to track every connection that's ever sent a WRITE > to a given file. Just remember the first one, with a flag to track > whether anyone else has ever written to it. > > ?? > > --b. -- Chuck Lever
