Subject: [nfsv4] word smithing changes for Chapter 18 - OPENATTR through REMOVE

From: "Mike Eisler" <[email-masked]>
Date: Fri, 11 Apr 2008 12:58:56 -0700 (PDT)

http://eisler.com/nfsv4-wg/2008-04-11-ch-18-openattr-remove.html

Also has the fixes Bruce asked for in LOCK, and some retention clarifications
David Black asked for.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Apr 2008 16:19:33 -0400

> Also has the fixes Bruce asked for in LOCK, and some retention clarifications

Just curious--what's the rationale for the OPEN_DOWNGRADE change?  (To
summarize: the spec has always said that the OPEN_DOWNGRADE share bits
must be equal to the union of some subset of the existing OPENs.  After
this change, servers MUST return INVAL when this fails, whereas
previously that was optional.)

The tradeoff isn't clear to me: on the positive side, you help identify
client bugs.  On the negative side, the server may have to do a little
extra bookkeeping, and may trigger failures in cases where perhaps it
could otherwise have continued on without terrible consequences.  My
incliniation would've been to continue to leave that choice to the
server implementation.

But maybe I'm missing the point.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Apr 2008 16:23:57 -0400

> Also has the fixes Bruce asked for in LOCK, and some retention clarifications

One very minor comment: there are some (very nice) tables of attributes
which have an "Acc" column that looks like, e.g.:

	RD
	RD
	R/W
	R/W
	WRT
	RD
	RD
	...

I might find that easier to scan if it looked like:

	R
	R
	R W
	R W
	  W
	R
	R
	...

--b.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 11 Apr 2008 16:37:24 -0400

I don't have a strong feeling either way on this but one positive to
making this change is to  improve interoperability.  Any time you give
the server an option like this you are creating another situation in
which a client can work fine with one server but not with another and,
unless there is a good reason for that, we are best staying away from
it.

In this particular case, I think I wrote the original text in RFC3530
and I was worried about the server needing to keep a data structure for
each open, which is not something it would have to do otherwise.  It
seem though, that all the server would have to do is keep a bit-mask of
all the open modes issued for a given stateid.  This would be twelve
bits long (3 access modes times four deny modes) and would mean that you
wouldn't need per-open data structures.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 4:20 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] word smithing changes for Chapter 18 - OPENATTR
throughREMOVE

--b.

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 11 Apr 2008 13:57:24 -0700 (PDT)

> previously that was optional.)

I'm not sure what you are referring to.
Draft 21 and RFC3530 say the same thing, which is:

   The
   share_access and share_deny bits specified must be exactly equal to
   the union of the share_access and share_deny bits specified for some
   subset of the OPENs in effect for current openowner on the current
   file.  If that constraint is not respected, the error NFS4ERR_INVAL
   should be returned.

I merely broken this into a list with separate items for access and
deny.

The only NFS4ERR_INAL I added was to require the arguments be
valid values.

E.g. I send an OPEN_DOWNGRADE that changes the access state from
OPEN4_SHARE_ACCESS_READ to zero. Is this is acceptable? What does it mean?
Why not use CLOSE?

> But maybe I'm missing the point.

The other thing that motivated this is that a bunch of bits got
added to the OPEN operation to enable "wants":

  /* new flags for share_access field of OPEN4args */
  const OPEN4_SHARE_ACCESS_WANT_DELEG_MASK        = 0xFF00;
  const OPEN4_SHARE_ACCESS_WANT_NO_PREFERENCE     = 0x0000;
  const OPEN4_SHARE_ACCESS_WANT_READ_DELEG        = 0x0100;
  const OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG       = 0x0200;
  const OPEN4_SHARE_ACCESS_WANT_ANY_DELEG         = 0x0300;
  const OPEN4_SHARE_ACCESS_WANT_NO_DELEG          = 0x0400;
  const OPEN4_SHARE_ACCESS_WANT_CANCEL            = 0x0500;

  const
    OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL
    = 0x10000;

  const
    OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED
    = 0x20000;

These bits should not be part of OPEN_DOWNGRADE, yet as
currently written in draft-21, they implicitly are.

So I don't see what has changed. Perhaps you have counter
example that will make it clear what has changed.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Apr 2008 17:00:19 -0400

> unless there is a good reason for that, we are best staying away from

Yeah, fair enough.

I'd prefer this sort of thing be a SHOULD if only to make it clear that
the error return is provided as a client debugging aid, not as behavior
anyone should really depend on.  (Not that I can imagine any reason a
client would want to depend on this particular error return.)

> wouldn't need per-open data structures.

Yeah, that's more or less what the linux server's doing.  And I recall
that after we added those checks we did catch a client or two.

(Hm, now that I look--we actually have two separate bitmasks--3 for
allow, 4 for deny--so we wouldn't catch downgrades that'd be correct
individually considering either the allow or deny bits, but would be
wrong together.  Whatever....)

Anyway, my worry is less resource consumption than: oh goody, one more
(admittedly small) bit of code to get right to implement an already
complicated protocol.

It's not a big deal, though.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Apr 2008 17:17:23 -0400

>    file.  If that constraint is not respected, the error NFS4ERR_INVAL

Weird: actually, the above language is from RFC 3530, but draft 21 has
it as a "may":

	If that constraint is not respected, the server may return the
	error NFS4ERR_INVAL.

> I merely broken this into a list with separate items for access and

You also made the above should/may a MUST:

	"If the above constraints are not respected, the server MUST
	return the error NFS4ERR_INVAL."

> OPEN4_SHARE_ACCESS_READ to zero. Is this is acceptable? What does it mean?

Of course, I agree--that's not acceptable.  My question was just whether
we need to require the server to be so diligent about catching all these
corner-case client misbehaviors.

--b.

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 11 Apr 2008 14:31:56 -0700 (PDT)

> 	return the error NFS4ERR_INVAL."

Ah. I'll make it a SHOULD.

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 11 Apr 2008 15:46:40 -0700 (PDT)

> I might find that easier to scan if it looked like:

OK

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/