Subject: RE: [nfsv4] An issue regarding free byte-range lock state

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 1 Jul 2007 10:59:43 -0400

I'm conivnced we need OLD_STATEID is some cases.  The 
cases where we need it are on CLOSE and OPEN_DOWNGRADE 
to deal with the possibility of a pending OPEN of a
hard link.

On the other hand there doesn't seem to be much point
on OLD_STATEID on READ, WRITE, LOCK.  If you are returning
OLD_STATEID in those cases, you are forcing retry to
give the server the stateid-sequence without much
point.  The server has the other part and can check the
current state regardless of the stateid sequence.

So here is a proposal: The server always sets sequence
in the stateid and the client can look at it, if it wants.
When sending a stateid, the client may sent the latest
seqid or zero, as a wild-card.  Zero is always accepted
but if a non-zero value is sent it must be the correct one
to be accepted (if it is too high BAD_STATEID, and too low
OLD_STATEID).  The recommendation is that clients will 
typically send the seqid on CLOSE and OPEN_DOWNGRADE
for the resons demonstrated by Peter's example.  On the
other hand, if they only have one outstanding request
per owner, they don't have to do this and are OK sending
zero as the seqid.

-----Original Message-----
From: Peter Varga [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 5:09 PM
To: Spencer Shepler; [email-masked]
Subject: RE: [nfsv4] An issue regarding free byte-range lock state

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]]
> 
> If the client choose to have more than one outstanding 
> OPEN/OPEN_DOWNGRADE/CLOSE for an open_owner, then the seqid is 
> required.  Because of hard-links, there are issues of OPEN upgrade 
> given that NFSv4 requires that downgrade be done in the opposite 
> pattern from upgrade; this means the client needs to know the ordering

> of the state changing operations.  Then there is the race between 
> OPEN/CLOSE that can occur, again in the presence of hard-links.
> 
> Spencer
> 

I see. In that case, we still need the OLD_STATEID error (spec says "
This error does not apply to and should never be generated in NFSv4.1.")

Consider:

- link1 = link2 = hard links
- stateid1 and stateid2 refer to the stateid in its entirety (seqid +
other)
- same open_owner

If the server does _not_ increment stateid.seqid:
client sends OPEN link1
client sends OPEN link2
server returns stateid1 in response to OPEN link1 client sends CLOSE
stateid1 server returns stateid1 in response to OPEN link2 server closes
stateid1 in response to CLOSE stateid1 client sends READ stateid1 server
returns BAD_STATEID --> Problem!

If the server increments stateid.seqid:
client sends OPEN link1
client sends OPEN link2
server returns stateid1 in response to OPEN link1 client sends CLOSE
stateid1 server returns stateid2 in response to OPEN link2 server
returns OLD_STATEID in response to CLOSE stateid1 client figures out
link1 and link2 are the same file and doens't resend the CLOSE

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

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

---

From: Spencer Shepler <[email-masked]>
Date: Sun, 01 Jul 2007 12:04:00 -0500

> to deal with the possibility of a pending OPEN of a

Agreed.

> current state regardless of the stateid sequence.

Do we have a desire to provide fencing in the case
of mandatory locks?  I am thinking of the case that the
client (or server) has made a mistake in its record
keeping and there may be in-flight read/writes that
don't match the mandatory file locking state.

I don't have a strong opinion -- a slight preference
for the stateid.seqid on read/write to provide for this.
So, whatever everyone else wants.

> per owner, they don't have to do this and are OK sending

Yes.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 5 Jul 2007 10:35:54 -0400

> don't match the mandatory file locking state.

If the client makes a mistake then the server still has
the correct current locking state, so the IO can be 
rejected if it is from the wrong owner, just as it will 
be if it is from a different client.

As to the server making a mistake in its record keeping, I
just don't know what you can do about that.  If you assume
that the server might be wrong about what mandatory locks
are held, it just as well might be wrogn about what the
correct seqid is.

> So, whatever everyone else wants.

Allowing the seqid to be sent or not as the client chooses
allows this.  What I really don't want a scheme that forces 
the seqid to be sent, even when the locks are not mandatory,
which is going to be a commmon case.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Sunday, July 01, 2007 1:04 PM
To: Noveck, Dave
Cc: Peter Varga; [email-masked]
Subject: Re: [nfsv4] An issue regarding free byte-range lock state

Agreed.

Yes.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 05 Jul 2007 13:01:30 -0500

> which is going to be a commmon case.

This is fine with me.

The final question I would like to resolve in this thread is
the one I asked about the requirements or use of the
stateid4.opaque portion of the stateid.

What are the requirements on the server about the contents
of this field?  Once the stateid is established as a
result of OPEN, is the server allowed to change the
value of stateid4.opaque as a result of subsequent OPEN (upgrade),
OPEN_DOWNGRADE?  The same question applies to the LOCK stateid
and the sequence of LOCK and LOCKU operations.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 6 Jul 2007 16:49:31 -0400

My preference would be that the server in both of these
cases MUST return the same stateid4.opaque field and an
stateid4.seqid.  This would allow the client the 
flexibility to send a seqid of zero in cases where he
didn't care which instance he acted on, a non-zero value
in those cases in which he did.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 2:02 PM
To: Noveck, Dave
Cc: Peter Varga; [email-masked]
Subject: stateid4.opaque requirements (was Re: [nfsv4] An issue
regarding free byte-range lock state)

This is fine with me.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 06 Jul 2007 16:26:32 -0500

> in those cases in which he did.

This is fine with me.  Just wanted the specifics given
the significant change from 4.0.

Spencer