Subject: more on seqid#s

From: [email-masked]
Date: Mon, 29 Jul 2002 10:52:44 -0400 (EDT)

Great, thanks Dave and Dave.

Ok, so if I understand what you guys said, the seqid#s that the server
uses to order requests are the open_seqid and lock_seqid ones and not
the seqid in the stateid (which makes sense, since the stateid is generated
by the server). Does that sound ok?

Now, what is the server supposed to do with the seqid# in the stateid?
Set it to the value of the open_seqid/lock_seqid for that request (or
that number plus one or...)?

Now, one more mystery to me. Why does the open_to_lockowner arg for the
lock op have both open_seqid and lock_seqid? (I've never been able to
decide if open_owner and lock_owner are the considered the same or distinct
and how they relate to each other?)

Anyhow, thanks for the info and sorry for being a pest, rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 Jul 2002 09:19:23 -0700

> that number plus one or...)?

Start with zero when one has a new stateid sequence (that is a new 
combination of owner and file) and increment it by one for each change
(via a successful lock, unlock, open which results in an upgrade, 
open-downgrade) to the stateid thereafter.

> and how they relate to each other?)

This arises from the situation that a process can open a file, fork,
and then have a number of distinct processes get locks for that same
file.  Given that context, open_to_lockowner is conceived of as making 
a state-related change that must be sequenced within the sequence of 
open-related requests for the original opener and the the lock-related
requests for the locker.  I think the argument could be made that you
could get away with less, but it seems iffy to me.  Rather than have 
that big discussion, I think we settled on something that we knew would
work, even if it might not be minimal.

My server at least treats the the two sorts of owner as distinct.  That 
is, a lockowner and an openowner with the same string are different 
objects that have no necessary relationship with one another, even 
though typically the lockowner and the openowner that share a string, 
will really, on the client, be the same process.

> Anyhow, thanks for the info and sorry for being a pest, rick

Asking questions so one has an implementation that can interoperate
with others, doesn't seem to me like something that one should have to 
apologize for (as opposed to ending a sentence with a preposition which 
is something that I'm going to offer a completely insincere apology 
for :-)