Subject: RE: issue with LOCK being able to return an update open_stateid

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 5 Sep 2002 08:24:04 -0700

Spencer Shepler wrote:
> On Wed, Noveck, Dave wrote:

<deleted>

> > Now in your case, we are assuming that all of this is done by a single
> > process so the tranposition of the lock and IO is not quite so obviously
> > harmless, but I still argue that this is a case of "No harm, no foul"
> > since the fact that you (validly) issued the IO with no lock implies 
> > to me that the server is perfectly justified as treating this issued
> > by an anonymous null lockowner (one that has no additional locks). 

> Yes. I agree with your assessment if we have a single process that is
> opening and locking a file.  As an example of where a problem may
> occur would be if a process were to open a file and initialize it with
> some amount of data.  It then would fork a number of children that
> would each then use file locking to interact amongst themselves for
> access to the data.  In this one case, the protocol will not provide
> the appropriate protection for the instance mentioned above.

Interesting case.  I can see that you might want to have a barrier
here, at least at the point where the first lock of the first process
to lock is done.

> > > The client does not have any additional serialization beyond what is
> > > needed today since the client must serialize its requests via the
> > > open_seqid.  Therefore, no additional burden for the client.
> > 
> > There is no additional serialization among LOCK requests, but there
> > is additional serialization between LOCK requests and IO's.  If one
> > process is doing IO's and another process gets its first lock, then
> > you have to serialize there, where otherwise you wouldn't have to.
> > In particular, IO's that were validly issued may come, when processed
> > to have old (open) stateids, because another process using the same open
> > go a lock.  So you might have to reissue such IO's.  This isn't a very
> > common case, but you have to deal with it.

> When I mentioned serialization, I should have made it clear that I was
> speaking of client serialization the lock sequence id.  As we have
> discussed before, the client doesn't need to serialize the sending of
> these requests if it is prepared to handle errors returned from the
> server in the event that the requests are processed "out of order"
> with respect to their sequence ids.  In any event, this really doesn't
> have a impact on the decision to change the LOCK response.

> > > This change is easy to make in implementations because the LOCK
> > > processing in this case will have access to the necessary data
> > > structures for checking the open_seqid and generating the new
> > > lock_owner data structures.
> > 
> > The big issue for me is that it's another over-the-wire protocol change
> > at a time when each such change complicates development and testing.
> > Having the July protocol, the August protocol, and now the September
> > protocol just adds confusion tracking down mismatched clients and
> > servers.  It pushes off the time when one can assemble a set of
> > multiple clients implementing the same protocol and test against
> > your server implementing that same protocol.  (Transpose for those
> > implementing and testing clients).

> I agree that we need to be prudent with any potential protocol changes
> but if we know something is broken and likely to cause problems then I
> would hope that we would fix it.

> So the question to the WG is: is this particular scenario broken
> enough to fix it now?  Or should we leave as is and when/if this ever
> breaks in practice we fix it in a minor version.

I think it is possible to address this (and other potential issues)
with something that is less disruptive than your proposal.  The idea would
be to create a new IO-barrier op.  You give it a stateid (either lock
or open), it returns a new bumped stateid in the same sequence, which
has the effect of invalidating pending IO's issued with the old stateid,
since they will now get OLD_STATEID.

You could then add this to the compound, in the from_open case, if you 
needed to, and potentially in other situations where it turned out
to be desirable, even potentially giving applications a way to force it
to happen.

Servers could implement this without breaking compatibility with existing
clients.  Clients would need a mount option if they wanted to use this 
until all servers were upgraded, but I think this would be a lot less 
disruptive to interoperability testing than an incompatible change to LOCK.  
It also has the advantage of allowing us to address similar issues in the 
future without a protocol change.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 5 Sep 2002 16:00:42 -0500

On Thu, Noveck, Dave wrote:
....
> future without a protocol change.

So based on my last post and this one from Dave, I am going to
consider this issue closed and the WG will address the issue in the
future if the need arises.

-- 
Spencer