Subject: RE: Spec-related discussions at the Bake-off

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 4 Nov 2000 06:31:57 -0800

> The original designed purpose of seqid was to create an at-most-one
> semantic
> for locking operations, thus if the stateid is changed then a seqid
> must have changed and vice-versa.

> Originally the seqid and stateid number space was supposed to be
> maintained on a owner/file pair which allows concurrency and doesn't
> force synchronization of I/O operations with state change on different
> files.

> What appears to have happened is in order to solve the problem of
> at-most-once semantics the existing seqid was used across opens
> and this forcing it to be a single number space for each owner. Because
> of the tying to stateid it also becomes a single number space for
> each owner.  This is unfortunate.

If the scopes of the seqid and stateid spaces are both the same
(either both being per-lockowner or both being per-lockowner+file),
then yes, stateid and seqid, get changed in tandem.  That is, if
this were so, they would be tied.

However, if the two scope are different (seqid as per-lockowner,
stateid as per-lockowner+file), which is one of the two possible
interpretations of the spec as it stands (I think the better one),
then they are not tied together.  This tying (or not) is an effect
of choices you make.  It is not, as far as I can see, an independent
justification for making the two scopes exactly the same.  Why
is it necessary to tie these two together?

> A possible resolution of this issue is to separate the seqid number
> space for share locks from record locks. In other words, the seqid
> space used to manage all OPENs is independant of the seqid
> space used once the file has been successfully opened. This should
> then also allow the stateid space to be maintained on a per owner/file
> pair as well with the stateid returned from the OPEN being the initial
> stateid for that file.

My gut feeling is that this is a bad idea.  The Law of unintended 
consequeneces in very strong in this area.  To try to do this with the
constraint that no parameters of any operations change (so we can
say we are "not really changing anything") in a short time seems
at the least very risky.

> I believe that this change can be managed without changing the wire
> protocol but by simply clarifying the semantics in the specification.

If you are changing the numbers that clients must send to work properly,
you are changing the wire protocol, even if the .x file does not change.

We have two possible interpretations of this issue in the spec as it 
stands.  Let's pick one.  That at least is arguably a clarification.
Here are the pluses and minuses:

All scopes (seqid and stateid) per-lockowner:

    + It is simpler

    - It exacerbates the synchronization problems between locking reuest
      and non-locking requests that accept stateid (mainly read and write).

    + It is consistent with some details of the rqeuests signatrues such as
      the fact that CLOSE returns a stateid.

    ? It ties seqid and stateid together since they have the same scope.

Seqid scope is per-lockowner, stateid scope is per-lockowner+file:

    + It has better synchronization characteristics

    + It is the interpretation that has been implemented by all the clients
      and servers and they have tested together.

    ? It doesn't tie seqid and stateid together because each has a different
      scope.

Unless we are going to go through a round of honest change to deal with
another problem (e.g. Carl's downgrade issue), let's just pick one.

I don't think it's any surprise that I vote for the one I have implemented
to, but I can live with either choice.

Let's just pick one of these two interpretations and move on.

---

From: David Robinson <[email-masked]>
Date: Sat, 04 Nov 2000 20:41:17 -0800

>     ? It doesn't tie seqid and stateid together because each has a different

Given just two choices I would pick this one, it has more benefits
and less drawbacks, and is closer to what I wanted in the first place.
:-)

	-David