From: Noveck, Dave (dave.noveck@netapp.com)
Date: 06/23/99-04:00:51 PM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA03303659@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: I-D updates for OPEN procedure Date: Wed, 23 Jun 1999 14:00:51 -0700 > > > > > I have made some changes to the OPEN definition in the > I-D and have > > > included it below. > > > > > > Dave Noveck raised the question about exclusive create in the > > > environment of compound ops. Should there be a > restriction that when > > > an OPEN/EXCLUSIVE is done that the subsequent SETATTR must be in a > > > separate RPC request? > > > > If you do put the SETATTR into the same RPC, it isn't going to work > > right. > > > > The spec should tell you that rather than forcing people to rely on > > folklore. > > Obviously. I plan on adding text to the I-D in any case. My > question is > more direct in that should the specification use the appropriate MUST > language about the problem and the solution of not combining the > operations? I would say yes, but if-you-do-it-you'll-be-very-sorry language is OK with me too. > > > > There is also the issue of where the exclusive create verifier is > > > stored at the server. As currently written, the server > has discretion > > > about where the verifier is stored. The client is > supposed to set the > > > 'attributes' to reset the verifier storage location. For > Unix server's > > > the verifier is usually stored in the modification time attribute. > > > However, this is convention. I wonder if there should be a psuedo > > > attribute that the client can set that will 'clear' or reset the > > > location used for the exclusive create verifier. This > would allow the > > > server to use any attribute field it likes for the > verifier and the > > > client will be assured that the verifier is reset. A > restriction will > > > still exist that the client may not depend on the values of the > > > attributes until the SETATTR(create_verifier) has been completed. > > > > I would say that since the server is allowed to store the > verifier in > > any attribute, by doing a SETATTR of any attribute, for a > file in that > > state, the client accepts that the verifier may be (and > should be) reset. > > So I would say that the server should in fact reset the > verifier whenever > > a SETATTR is done on a file in that state. This requires that the > > server have a bit in the inode that is set to mean that > modify-time or > > (whatever attribute is used) is really a verifier, so it > can detect when > > a SETATTR is being done on one of these nascent files. > > Which SETATTR from which client from which client entity does > the server pay attention to? :-) > > If the client has to ask specifically, then it can provide the > verifier and the server can confirm that the stored value matches > the client provided value before clearing the verifier from > stable storage. OK, I (finally) get the point. Another way to do this is to create a new op, FINISH_CREATE_EXCLUSIVE, which is just like SETATTR except it has a verifier and only works on these nascent files, and resets the verfier. Ordinary SETATTR would be defined to return an error if done (presumably by somebody else) on such a nascent file. Allowing that SETATTR to go through is bad because any given SETATTR may or may not reset the verifier based on where that particular server happens to store the verifier which can lead to awkward interoperability timebombs.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:14 AM Z CST