On Wed, Jan 25, 2012 at 03:29:34PM -0500, Chuck Lever wrote: > > On Jan 25, 2012, at 1:55 PM, J. Bruce Fields wrote: > > > On Wed, Jan 25, 2012 at 12:41:27PM -0500, Chuck Lever wrote: > >> If SETCLIENTID returns a unique clientid4 that a client hasn't seen from other servers, the client knows that's a unique server instance which must be recovered separately after a reboot. > > > > Hm, but does it have to do the recovery with that server? > > If a client has a lease and open state on that server, it should do recovery if the server reboots. Yes, but does it have to do it against *that* server, or could it recover against another? Again, as long as failover is allowed, I think the latter is too. > > And if so, then how does that fit with failover? > > We were supposed to discuss that with Bill and Piyush. Maybe we can bring it up again at Connectathon. But my assumption is that fail over is supposed to look like a server reboot. That's what I assume too: but that means, if I'm a client, and I fail over from server A to server B, and server B gives me a STALE error: I don't know if that's just because I failed over, or if in fact A and/or B did just reboot. And from the point of view of the servers: they don't know if the state I'm trying to reclaim is state I previously held from server A, or if it's some other state that I previously held on server C (but then lost, unbeknownst to me, due to a network partition that lost my RENEWs to C). So I guess the servers would be stuck trying to track all that state across reboots? > The question is what clients does the server allow to recover, and which does it force to start fresh? Shouldn't it be enough for a server to remember nfs_client_id4 strings? > > > I mean, suppose the whole cluster is rebooted. From the client's point > > of view, its server becomes unresponsive. So it should probably start > > pinging the replicas to see if another one's up. The first server it > > gets a response from won't necessarily be the one it was using before. > > What happens next? > > Again, it depends on whether your clustering implementation shares state among all servers in the cluster. Assume for now it doesn't. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
