From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 03/11/02-11:22:08 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A8CA5@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: RELEASE_STATE locking type Date: Mon, 11 Mar 2002 09:22:08 -0800 Dan Trufasiu wrote: > My opinion is that we don't need RELEASE_STATE. I think there are cases in which it is needed, although they may not apply to your client. Suppose you have a file which is opened and remains opened while a large number of other process come into existence, lock and unlock the file (using the existing open), and then terminate. In that case, the requirements for state storage on the server are unbounded. If the server has no way of knowing that these other processes have ceased to exist, he would have to retain an unbounded amount of state storage. Close is the only way that the state could be reaped but there could be cases in which the file remained opened for months and large number of processes come into and out of existence to handle individual application requests. There needs to be some way of dealing with that issue. > Do somebody use it? If any client ever issued it to my server he would have got an error, so I'm guessing nobody uses it yet. > As we > just realized, without a strong wording in the protocol, this flag will be > used in the future implementations as a REALESE_ALL. I think we have the strong wording. Once we have a server that implements an error if locks are held, clients assuming that it is a RELEASE_ALL will soon find out otherwise. > I don't think that the > client has to take responsibilities in the cleaning of the server. Cleaning of the server (i.e. deletion of unused resources) is the server's responsibility. But if the client has indicated certain resources (e.g. a lock stateid and all that goes with it) are currently used, the server cannot (or rather may not) clean them up, until the cleint indicates that he is no longer using them. Close is one way of the client doing that and it works pretty well for most cases. Release_state handles the others. > I'm just > curious: How a client can decide efficiently that an application will not > lock a file anymore? He only has to decide that a given lockowner will not lock a file anymore. If a lockowner is equal to a process and that process terminates then it can't do anything including locking a file anymore. > -----Original Message----- > From: owner-nfsv4-wg@sunroof.eng.sun.com > [mailto:owner-nfsv4-wg@sunroof.eng.sun.com]On Behalf Of Noveck, Dave > Sent: Monday, March 11, 2002 9:56 AM > To: 'shepler@eng.sun.com'; nfsv4-wg@sunroof.eng.sun.com > Subject: RE: RELEASE_STATE locking type > > > I think these are reasonable answers but the result is kind > of ugly. Thinking about this some more, I've come to the > conclusion that the ugliness is inherent in using the wrong > tool (LOCKU) to do RELEASE_STATE. RELEASE_STATE doesn't unlock > anything, and it's parameters are entirely different that those > for unlock. > > How about this? RELEASE_STATE is made a new op. It has the > parameters open_stateid, open_seqid, and lockowner. Nothing > (except the error status) is returned. If you do this, then ... > > You don't have a locktype that is invalid in almost all contexts > except one (LOCKU). > > You don't have parameters that are passed but ignored (offset, > length). > > You don't return data that is undefined and the client needs to > ignore. > > You don't need any special exceptions to do the sequencing logic. > In this model, the sequencing information is stored in a context > that is not destroyed by the operation (the openowner context), > so everything works normally. This is appropriate since > RELEASE_STATE is the join correspnding the fork done by the > from_open case of LOCK. In the latter case, the sequence > information is relative to the openowner context since the > openowner is what we are changing by forking off a new state > sequence. Similarly, when we terminate the lock state sequence > and merge it back to the open, the openowner sequence context > is also the appropriate one. > > Of course my readiness to completely re-organize this fucntion > might have something to do with the fact that I haven't implemented > or started implementing the one that is currently in the .x file. > If people are attached to the current approach (because of having > implemented it or otherwise), I can implement what's in the current > .x and live with the ugliness. > > Opinions? > > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Saturday, March 09, 2002 11:44 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: RELEASE_STATE locking type > > > On Sat, Noveck, Dave wrote: > > Spencer Shepler wrote: > > > On Mon, Sergey Klyushin wrote: > > > > I looked through the mailing list and could not find description > > > > of RELEASE_STATE locking type. > > > > Could somebody explain this locking type? > > > > > > The RELEASE_STATE enum of nfs_lock_type4 is meant as a > method for the > > > client to communicate to the server that a particular > lock_owner will > > > non longer be locking the file. Generally, this would be > used by a > > > client who has a file open among several processes and > one of those > > > processes is exiting and has locked the file in the past. > The client > > > sends this to the server to notify it that the lock_owner will no > > > longer lock the file. The server is then able to release > the state > > > associated with that lock_owner. > > > > Is this type intended to be specified in a LOCK request or a LOCKU? > > I'm assuming that specifying it in a LOCKT is an error > (NFS4ERR_INVAL?). > > When I suggested as a solution that Kendrick raised (releasing state > at the server), I was thinking strictly of LOCKU. > > > If specified in a LOCK, I would assume that setting reclaim or > > new_lock_owner makes the request invalid. > > > > Also I'm assuming that offset and length are ignored. > > I would suggest we limit it to LOCKU to reduce semantic > interpretation. So for LOCK and LOCKT, the server would return > NFS4ERR_INVAL. > > For LOCKU with RELEASE_STATE, the offset and length are ignored. > > > What about the stateid returned? Is the server supposed to set to > > anything in particular (e.g. all zeros)? > > We could suggest all zeros but may leave it as "undefined". Any > strong preference? > > > There is an issue with RELEASE_STATE and our old friend, retry after > > lost reply. > > > > If a locking operation is re-issued, then the sequence > information would > > normally allow the server to determine that it is a > duplicate and allow > > fetching of the response information saved for the last > operation associated > > with that owner. In the case of RELEASE_STATE, the server > would have > > released that information, including the sequence > information and anything > > that would enable the stateid to find that > previous-operation information > > which has been freed anyway. That's the purpose of the > whole operation > > after all. > > > > This situation is somewhat analogous to a retransmitted > CLOSE but the > > difference is that with a CLOSE, you have an owner scope > (and thus the > > scope in which seqids are interpreted) which is larger. You can > > leave the state structure around, pending its deallocation when the > > netx new operation for that owner arrives. In the case of > RELEASE_STATE, > > there will never be any such next operation. The > RELEASE_STATE is the > > last one. > > > > So I can't see anything happening but that the second RELEASE_STATE > > will not be able (or may not reliably be able) to find information > > corresponding to the stateid it recieves. So I would > expect it to return > > BAD_STATEID. In this situation, the client could accept that as an > > indication that there is no STATE to release any more (and > he generally > > would be right). On the other hand, it seems really ugly for the > > client to ignore such an error. Maybe the server should > return OK in > > this case, since he has been asked to release all of the asscoiated > > state for that lock stateid and if the lock stateid isn't > valid, there > > isn't any, so he has released all there is. Of course, that seems > > pretty ugly too. I think we need to pick one of these ugly > alternatives > > and go on. (Unless someone has a bright idea). > > Good catch. Since the use of RELEASE_STATE is meant as a method of a > nice client informing the server about the release, my preference > would be to have the server return NFS4_OK in the case that there is > no match for the stateid supplied by the client. > > However, if there is a match on the stateid, the server should apply > the traditional logic towards checking of the sequence-id. > > > > This is not meant to be a way for the client to release > all locks for > > > a particular file. The client is still responsible to do > this. In > > > fact, if the client were to use RELEASE_STATE when file > locking state > > > is still held for the lock_owner, the server should > return an error to > > > the client. NFS4ERR_INVAL appears to be the most > appropriate error. > > > > I propose we rename NFS4ERR_INVAL to be > > > NFS4ERR_YOU_DID_SOMETHING_WRONG_AND_I_AM_NOT_GOING_TO_TELL_YOU > _WHAT_IT_IS :-) > > I would go for that except the corresponding line in the .x file would > extend beyond 80 characters. :-) > > Another, shorter suggestion? How about NFS4ERR_PSTPPHHH? (a mimic of > the sound of the cartoon character sticking its toungue out) > > -- > Spencer >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:35 AM Z CST