From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 08/09/02-10:40:38 PM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A900D@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.t xt Date: Fri, 9 Aug 2002 20:40:38 -0700 > >>>>> "Dave" == Dave Noveck <Noveck> writes: > > Dave> I just don't understand how that scenario depends at all on > Dave> the fact that you are allowing locks to be held beyond the > Dave> expiration of the lease. > > You raise a good point. As long as the spec lets the server hold > locks beyond the expiration of the lease (and the client has no way of > telling whether the server takes advantage of that), it appears that > the server must record lease expiration information in stable storage. That's not my point. My point is that the server must record lease expiration information in stable storage whether the spec lets the server hold locks beyond the expiration of the lease or not. > If the client knew that the locks had to be dropped (either because > the spec required it or the server told it that that's what the server > will do), then when the client realizes that the lease has expired, it > will not try to reclaim its locks. I don't see that the client has enough infomration to make the distinction you want to make, unless you are prepared to adhere to it so strictly that essentially locks could never be reclaimed. Look at the following sequence of events, as seen from the client. Suppose the lease period is 50. At t, client gets a lock. At t+40, it sends a renew. No response. It keeps sending (UDP) or not (TCP) but in any case, possibly after one or more connecion breaks, it gets back a STALE_CLIENTID error, at t+100. Can the client reclaim his locks? I would expect that he can and if he can't in that situation, when could he ever reclaim them? The most likely scenario of what happened is that sometime between t and t+40, the server went down, rebooted and was back up at t+100. I suppose that if the server rebooted and was back up by t+50, then the client could know that his lease could not have expired, but I think this would be an unusual case, and so I don't think you can make reclaim conditional on it. But if we have the situation above, then we can certainly have a case in which after t+50, the locks are released, someone else gets and releases a conflicting lock at t+51 and t+52 respectively, and everything is the same from our client's point of view. The client does not have the information to decide if he may reclaim (even if you trusted him). The server has that information, if he keeps it in stable storage. > I'm not happy with the complexity introduced by letting servers hold > onto locks after the lease expires, so I would not shed any tears if > it were removed from the spec. But there would be no real simplification in the spec. If you don't want to implement this, you don't have to and I don't think it adds complexity for those that don't impleemnt it. > But it seems like the client has to be careful about detecting lease > expiration, to avoid the following scenario: > > Client gets lock > Client submits RENEW request on time, but it gets delayed (e.g., > network congestion) > Lease expires -- lock release > one second later -- Conflicting lock request > second client does an unlock > server reboot > First client retransmits RENEW request and gets STALE_CLIENTID > from server > First client reclaims his lock > Server erroneously grants reclaim Exactly the scenario, but, there is no reasonable degree of care that the client can exercise to avoid this. Take away the omniscient narrator, and let the client tell his story: "I got a lock. I submitted a renew request on time. Then later I got a STALE_CLIENTID error. Then I did a reclaim. What was I supposed to do?" Is this a case of justified reclaim or should we take him downtown and beat a confession out of him?
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:11 AM Z CST