From: David Robinson (robinson@jetsun.eng.sun.com)
Date: 11/16/99-02:08:27 PM Z
Date: Tue, 16 Nov 1999 12:08:27 -0800 (PST) From: David Robinson <robinson@jetsun.eng.sun.com> Message-Id: <199911162008.MAA14423@jetsun.eng.sun.com> Subject: RE: leases revisited was RE: Some issues with stateid's > Right now, the need is that the spec requires it. I don't > know how to read Section 8.4.2 in any other way as saying > that you have to keep a sequence number for a given lockowner > which is montonically increasing (BTW, it should make clear > that it is incremented by one each time. Monotonically > increasing, while true, is misleading because it is > insufficiently restrictive. I think Neil Brown pointed > this out). It says that the sequence is reset when the > client verifier changes, implying that it isn't reset at > any other time. Ok, I am stupid, I can't find 8.4.2 in any of the drafts on playground. The only need to keep a sequence number between OPENs is if we have required at-most-once semantics to OPEN operations. Otherwise it is sufficient to maintain the seqid and lockowner for the duration of the OPEN/CLOSE period. Do we care about at-most-once OPENs? If we define multiple OPENs with the same lockowner as state invariant then it shouldn't matter. > I agree that the specification of the error should not be > written in terms of a stateid-as-a-triple. But I do think > the spec should mention this somewhere as a possible > implementation. I think the spec currently discusses > how a volatile filehandle might be implemented, so this > kind of thing has been done before. I actually preferred your descriptions in quotes: "There may have been such an agreement at one time but there isn't now and I don't remember it". > As far as the (r < L) case, there is a very small effort to send > back the error response which, if everyone is playng by the > rules, will get ignored. On the other hand, returning an error > is something servers know how to do while silently ignoring > a request is fairly strange. It's particularly strange > when you may have already executed a number of ops including > state-modifying ops. It just seems that an error is cleaner > here. I have no trouble sending the error that should be ignored back, it is likely a useful piece of information in some debugging cases. > For (r > L+1) case, I still don't see the point of ignoring > the error. I believe that the whole mechanism assumes that > clients should not have more than one locking request for a > given lockowner outstanding at a given time. (I think it > would help to make this explicit). In this case, if a > client runs into the (r > L+1) case, it is because he is > doing something wrong. The best way to have him find the > problem is to return an error. You may want to log something > as well, but not returning an error is going to make the > problem harder to find. Again, from a theoretical perspective it is unnecessary, reality would probably indicate it wise to error anyways. > It may be too late. I think if we do this, then stateid's > should always be specified implicitly, just as file handles > are. Magic values to allow them to be specified either > explicitly or implicitly, is just too complicated. Neil > Brown recently posted a proposal to do this. My fear is that we are in a rush to close the spec even though no one has prototyped the locking portions yet. There were changes made due to the simple ops being prototyped so we should not be in too big a hurry to nail the lid shut. > Unix has no concept of shares but it can be affected by the > reservations of others. So, if a Windows client opens a file > ACCESS=READ DENY=WRITE, then my subsequent Unix OPEN for write > should fail. At least, I assume so. Yup. > So now suppose that a Unix process opens file A/B for reading > and then a Windows client opens that same file specifiying > ACCESS=READ DENY=WRITE. Now if my original process were to > do an additional open of A/B for read-write, what do we do > now. Can I just do an OPEN (with the same lockowner) and > have that fail because of the share reservation? (In fact, > even without needing to the the denial for the share > reservation, I probably need to do an OPEN to get a stateid > that will allow me to write the file; also the server > needs to know that I am writing so that it can deny > subsequent share reservation requests from Windows clients). I would expect the subsequent OPEN (or CLOSE/OPEN pair) would fail due to the DENY=WRITE. > So I think the server needs in some way to support the > concept of upgrading downgrading a lockowners current > access. This might be by somehow allowing multiple > OPEN's with different access or in sme other way. > As the spec now stands you can't allow multiple OPEN's; > there is no way that you can specify to CLOSE that > you want to close one or the other of the two open's > you have outstanding. Why can't we require a COMPOUND op with a CLOSE/OPEN pair? > Suppose process 100 opens file X/Y and then forks process > 101. Unix thinks that process 101 has the file open and > can get record locks but the server doesn't. He doesn't > have a stateid corresponding to process 101. He could > use the process 100 stateid to do IO but if he wants to > get a record lock, then using this stateid would result > in getting locks for process 100. So if process 100 and > process 101 were to try to use locking to co-ordinate > their access to the file, it wouldn't work. Maybe > we should go back to having LOCK take a lockowner > rather than a stateid. Since fork() loses all locks, process 101 effectively has a filehandle as the result of a LOOKUP without OPEN. If it wishes to participate in locking it must reOPEN the file to get a new valid stateid. > One question is what happens when you try to unlock the > revoked one. I think that should be OK and not an > error. Either the server doesn't error, or clients ignore the error. I would prefer the latter as that is how things mostly work today. On close everyone just ignores errors. > On the other hand, CLOSE does take a stateid so if you > have a revoked lock, as things stand that stateid should > be invalid. I think the spec should allow you to use > stateids that are invalid (because they include a revoked > lock) if you are just giving up locks. If the stateid is invalid then the server may have no way to use the value reliably. So it is dubious to allow it. > One other thing was the issue of whether 64 bits is enough > as a stateid. Since this would be hard to change with > minor versioning (needs old and new versions of LOCK, LOCKU, > OPEN, CLOSE, READ, WRITE, DELEGRETURN), I'd like to make > sure we have enough room. In our earlier discussions we talked about how an implementation could use pointers and needing a triple to represent it. If you look at how often a stateid will change then 64-bits is probably enough and a good server can pack all the information in easily. So I am unmotivated to expand the field when most of the bits will be static and compaction is a well understood science. > One other other thing is the issue of trying to make sure > that all leases for a given client always expire at the > same time (as opposed to the current spec in which this is > almost always the case). We discussed this a while back. All leases for a client should expire at once, to do otherwise unnecessarily complicates the protocol and has a strange implication that the client/server would be able to maintain some of its state but not other. We should tighten up the spec to remove the "almost always" for everything except an adminstrative revocation. -David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:55 AM Z CST