Subject: Re: Re: [nfsv4] Out of sync stateid...

From: [email-masked]
Date: Fri, 12 Sep 2003 12:26:33 -0400 (EDT)

> I was really referring to the case in which 2 different processes OPEN
> a file using the same open_owner:
> 
> Assume process 1 opens the file for write only, and sets a byte range
> lock (defining a lock_stateid in the process). What happens when
> process 2 opens the same file for reading?

My understanding is the Open becomes (Read | Write) on the server. (see
4th last para under Description in sec. 14.2.16) I would also argue that this
can be considered a "state change" and, therefore, the server might change
the stateid to reflect that. (There is also a statement w.r.t. this for
Open ordering, right at the end of Sec. 2.2 under the definition of a
struct stateid and I would argue it implies the seqid in the stateid should
change in this case.)
I would also argue that the definition of NFS4ERR_OLD_STATEID in Sec. 8.1.3
also implies that the server will generate an error for a stateid that doesn't
refer to the "current locking state" and the client needs to avoid that.
(I do find Sec. 8.n confusing, because it never refers to
an openowner, always a lockowner. NB: When you look at the above
reference in Sec. 14.2.16, it also uses lockowner in the discussion on
Open.)

> Is the lock_stateid
> invalidated together with the open_stateid?

My understanding is no, but I don't think the RFC actually states that.
(In fact, the only places in the RFC that seem to discuss
open and lock stateids are the last para. of Implementation in Sec. 14.2.10
and in Sec. 2.2 under the definition of struct open_to_lock_owner4.
The recent discussion I was involved in w.r.t. the relationship between
opens and locks seems to imply these sections of the RFC aren't clear.)

> Furthermore, is process 1 then required to serialize its writes
> w.r.t. the OPEN call of process 2?

I believe that the definition of NFS4ERR_OLD_STATEID in Sec. 8.1.3 implies
yes, since that error might be returned if the client does not do so.

> How does it know a priori that the
> OPEN call actually refers to the same file on a server that allows
> hard links and/or renames of open files?

Yep, if the CFH is the same as the file handle for an existing open
then it is the same. If not, I think you are stuck disabling I/O ops
for all stateids on the same OpenOwner while an Open is in progress?
(Sec. 9.3.4)

     > The RFC doesn't require that a stateid change values on
     > operations like OPEN (upgrade) or OPEN_DOWNGRADE but it makes
     > the server implementation much easier with respect to tracking
     > a single valid stateid for a file.  The amount of state that
     > needs to be kept is a little less, the server can easily
     > determine if pending reads/writes fall under the appropriate
     > stateid, and when debugging client and server interaction it is
     > easier to track the transitions that occur with stateids.

I would have said that the statement at the end of Sec. 2.2 comes very
close to requiring it?

> Right, but given that we have a hierarchy of state (see the above
> example), can this be made consistent with the model I have suggested?

I don't know, but I'd say a client that chooses to use very few OpenOwners
isn't going to be implemented easily?

Hope this made sense, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Ronald E Bretschneider <[email-masked]>
Date: Fri, 12 Sep 2003 13:56:43 -0700

on 9/14/2003 rick wrote
   "(There is also a statement w.r.t. this for
Open ordering, right at the end of Sec. 2.2 under the definition of a
struct stateid and I would argue it implies the seqid in the stateid should
change in this case.)"

There is one aspect of the stateid4 definition which I have never
understood.

this is a fragment of the stateid4 definition:
"The server is required to increment the seqid field monotonically at
each transition of the stateid.  This is important since the client
will inspect the seqid in OPEN stateids to determine the order of
OPEN processing done by the server."

Can someone explain why the client will inspect the seqid in open stateids?
I thought that associated with each openowner was a sequence number.
Therefore, an openowner could have only one open, open_confirm,
open_downgrade,
close, or lock (with open_to_lock_owner4) outstanding at any one time. IOW
the
client would have to wait for one openowner's open to complete before
sending
another.  So, why is it that the client needs to inspect the seqid in the
open stateid?

thanks,
Ron

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 12 Sep 2003 14:07:34 -0700

Even if a client were to speculatively have multiple sequenced 
requests outstanding for the same openowner, he would know that 
they would be processed in the order of the open_owner seqid
(or fail with BAD_SEQID), so I can't see him, even in that case,
having to look inside the stateid to determine the open processing 
order.

The client will set the stateid (including the seqid portion)
from the one he gets for the last open-type operation when he
issues IO operations for the given open file and this
will enable the server to determine what open state was in 
effect at the time the IO was issued.  But as far as the client 
himself looking at this stuff, I just don't see it.

-----Original Message-----
From: Ronald E Bretschneider [mailto:[email-masked]]
Sent: Friday, September 12, 2003 4:57 PM
To: [email-masked]
Subject: Re: Re: [nfsv4] Out of sync stateid...

on 9/14/2003 rick wrote

thanks,
Ron