From: Noveck, Dave (dave.noveck@netapp.com)
Date: 08/09/99-10:18:36 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10B9F@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Section 7.6 ??? Date: Mon, 9 Aug 1999 08:18:36 -0700 > > > Both sides will detect this state > > > > No. The server will detect this state and the client will > > deal with the consequences for each of its locks. There is > > no way that I can see that a client rushing to renew using > > some IO that happens to come along is going to know if he > > was in time. He may think he had 500ms to spare but some > > network problem means his message gets delayed. He can't > > use the success or failure of the IO since the fact that > > the IO succeeded doesn't mean that the lease was renewed; > > it just means that if it wasn't then no conflicting lock > > was given out corresponding to that stateid. You may very > > well have success for the IO when the lease renewal failed. > > If the lease has expired then the stateid held by the client > is invalid, > with an invalid stateid the IO operation must fail or risk corruption > (ignoring possible server optimizations where it can track no change > and allow the IO anyways). Thus the server knows the lease has expired > (its timer has run out) and the client knows it because any IO using > its "current" stateid will fail. If the IO has succeeded then the > lease must have been renewed because the stateids matched. > If the stateids > don't match then the client must go thru the recovery process of > revalidating the held locks. It is true that if the lease has expired then the stateid is invalid. The converse is not true. If the stateid is invalid, you cannot assume that the lease has expired. All you can assume is that either the lease has expired or that the lock has been revoked. I'm really having trouble understanding what is intended here. First, the basic assumption is that if the lease has expired then IO with one of the associated stateid's will fail. Leaving aside the question of what the client may validly assume in that case, let's focus on the procedure which he is asked to perform. He now issues IO's using stateid's for all of his locks. The idea is that this will somehow "revalidate" them. OK, so this means that the server is supposed to honor them and not give back an error. But these stateid's being revalidated are precisely in the same condition that the original stateid was. So, on what basis is the server going to honor those while giving back an error on the original one? Now, look at the case of doing two IO's to different stateid's soon after a lease expiration. Is one of them going to fail and the other succeed (by being revalidated)? What about an OPEN or LOCK that was in flight together with the IO? Do these have to be invalidated-revalidated also? The only thing that seems to make sense is that if there is server revalidation logic that it works for all of the stateid's involved uniformly. If that's the case, the client never finds out that the stateid he used was ever invalid and he doesn't go through any explicit revalidation procedure. For any stateid that were either revoked or which were given away to conflicting requests, the server is going to give back an error which the client will then deal with. > > > > and can recover without data corruption. > > > > Yes but not using the algorithm discussed below. > > > > > The client must mark all locks held as "invalidated" and > > > then must issue an I/O request, either a pending I/O or > > > zero length read to revalidate the lock. > > > > There's no way he can know that he has to do this (see above). > > What he should do is use the stateid's he has. When they > > are used in IO and corresponding locks have not been given > > to conflicting requestors (and the lease renewal had failed) > > then they will be upgraded to valid on the server. > > > > > If the response is success, the lock is upgraded to valid, > > > > No. If the IO succeeds, the client does nothing special. > > His lock remains valid just like any other lock from his > > point of view. > > This may not be worded correctly in the draft, but the stateid is > simply a short hand mechanism for the client and server to exchange > to indicate that they mutually agree on the files state > (locks and shares). > If any operation that changes the state causes a new stateid > is generated. > All operations that must respect the state of a file must use > a stateid, > if the stateid used by the client does not match the server's stateid > (either the client is sending a bad stateid or the server has > revoked it > due to a lease expiration). So in your above scenerio the > I/O must fail > or risk corruption. As far as principles go, I agree. > > I will agree that the current draft may not be well written on this. Right now, I can't understand what is intended by that section and exactly what logic the client and server should implement. The thing I'm worried about is that the lack of clarity is hiding a substantive problem behind it. I don't think that's the case, but until there is some clear agreement about how this is going to work, I remain worried.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:26 AM Z CST