Subject: [nfsv4] [3530bis] Item #8

From: Thomas Haynes <[email-masked]>
Date: Tue, 25 Jan 2011 21:55:55 -0600

> 8) Clarify the sections on sequence ids.
> 
> a) Currently, the text is inconsistent about whether or not you need
> to initialize them to zero.
> 

The two main passages that might be the victims here are Section
9.1.5 (page 112):

   was returned.  The first request issued for any given lock_owner is
   issued with a sequence number of zero.

and Section 2.2.16 on page 23:

2.2.16.  stateid4

   struct stateid4 {
           uint32_t        seqid;
           opaque          other[12];
   };

   This structure is used for the various state sharing mechanisms
   between the client and server.  For the client, this data structure
   is read-only.  The starting value of the seqid field is undefined.
   The server is required to increment the seqid field monotonically at
   each transition of the stateid.  This is important since the client

1) The proposal is to edit section 9.1.5 to state that the first request
is undefined. Note to implementors, zero would still be an acceptable
value here.

2) Note, I think the definition of stateid4 is wonky here, it should be:

   struct stateid4 {
           seqid4          seqid;
           opaque          other[12];
   };

Any reason it was a uint32_t?

I'm proposing to make this change as well.

> b) It would also be nice to have a section that clarifies the life cycle of
> a sequence id. IOW: when do the client and server have to cache the
> sequence id info, and when are they allowed to forget about it.

In re-reading the sections, all of the information is here, but not collected
in one place.

Does anyone feel that we need the additional verbiage on the lifecycle?

> 
> Action:
> Owner:
> State: Accepted, Medium
> Target:
> Notes: Trond votes get rid of having to initialize them to zero.
> 
> Belongs in lock owner bucket...

---

From: Rick Macklem <[email-masked]>
Date: Wed, 26 Jan 2011 08:39:08 -0500 (EST)

> Any reason it was a uint32_t?
Personally, I think it should remain uint32_t, since it is not directly
related to the seqid that is not in the stateid4. Actually, if you make a change
I think it should be renamed something else in order to clarify that it is
not the same as the one outside of the stateid.

Oh, and w.r.t. the seqid lifecycle. I think it is clear in Close that the seqid
(the one outside of the stateid that is used to serialize lock ops) that it ends
there, but it might be nice if the other section on seqid (8.1.5 in rfc3530?)
referenced that, as well. I believe that a lock_owner4 seqid created by
open_to_lock_owner4 used by a Lock Op cannot go away until the Close on the
OpenStateID in that open_to_lock_owner4, but it would be nice to clarify that,
as well, I think?

rick

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 26 Jan 2011 09:02:08 -0500

> OpenStateID in that open_to_lock_owner4, but it would be nice to clarify that,

RELEASE_LOCKOWNER will also kill the lock owner seqid/stateid in minor
version 0.

In minor version 1, a simple LOCKU suffices...

Cheers
   Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Robert Gordon <[email-masked]>
Date: Wed, 26 Jan 2011 09:13:06 -0600

> not the same as the one outside of the stateid.

i agree with rick. 

Robert.

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 26 Jan 2011 08:10:00 -0800

> I'm proposing to make this change as well.

I think changing data types is out of scope.

It breaks IDL compatability with RFC5661. So unless you want to atomically
take on RFC5661-bis, it should be left alone.

If you do want to take on RFC5661-bis, then change the data type to:

>            seqid4          st_seqid;
>            opaque          st_other[12];

And do the same (i.e. add prefixes to the field names) for all the other
struct/union.

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

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 13:01:32 -0500

> I think changing data types is out of scope. 

I don't know if it is.  This is changing uint32_t to something typedef'd
as a uint32_t.  Is that sort of compatibility with RFC5661 a
requirement?  I don't think that in coming up with RFC 5662, I thought
it was a requirement.  I didn't go out of my way to change things but if
I saw a type name that I thought needed to be fixed, I would have fixed
it without worrying all that much about it.  If you were the lookout for
this, then you would have caught it, but I was only concerned with OTW
compatibility.

There are changes for internationalization already in the draft
RFC3530bis that change the intermediate typedefs that such things as
pathname are derived from.  I didn't see that is a problem and I still
don't.

In other words we have:

RFC3530 has:

    typedef opaque     utf8string<>;
    typedef utf8string utf8str_cs;
    typedef utf8str_cs component4;
    typedef component4 pathname4<>;

Not that utf8str_cs refers to a stringprep profile which no longer
exists in RFC3530bis.  I think that (the non-existence of the profile)
is a good thing.

The draft RFC3530bis dot-x draft has:

    typedef opaque         utf8string<>;
    typedef utf8string     utf8val_should;
    typedef utf8val_should component4;
    typedef component4     pathname4<>;

utf8string has been left alone although I wouldn't call it "opaque".

We've discussed the applicability of these changes to RFC5661-2, but
doing this atomically seems a little bit much to ask.  I don't think we
should be in a situation where we have to fix all v4.x's at the same
time to fix a problem like this and when x > 1, it will get even worse.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Eisler
Sent: Wednesday, January 26, 2011 11:10 AM
To: Thomas Haynes
Cc: [email-masked]
Subject: Re: [nfsv4] [3530bis] Item #8

It breaks IDL compatability with RFC5661. So unless you want to
atomically
take on RFC5661-bis, it should be left alone.

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

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 26 Jan 2011 11:33:00 -0800

Yes, during the editing of the NFSv4.1 internet draft, any time Spencer
and you changed a data type inherited from RFC3530, I put it back.

Otherwise, when different names of data types are used, it is not always
clear they mean the same thing in various iterations, whether it is a
minor version, or in a BIS.

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 26 Jan 2011 13:52:03 -0600

> to initialize them to zero.

I.e., if these are two different beasts, then could the text actually be consistent?

In one case you do have to initialize to zero, in the other no one cares.

It doesn't change the fact that we can remove the restriction about having
to initialize to zero...

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 14:33:42 -0500

Fair enough.

> minor version, or in a BIS.

And the converse is that, given that basis you have established, when different name of data types are used, it will be clear that they mean different things in different versions, whether minor version or BIS.

So am I misinterpreting by concluding from this that the appropriate rule here is that a change in name should (capitalize, italicize, or put in a 72-point font as you wish) designate a change in referent?  If so, the conclusion would be that we want to avoid a change in name without a change in what is referred to or a change in what is referred to without a change in name.

So in the example of the change of definition of component4 in between RFC3530 and RFC3530bis, the change in name of the type source reflects the change from a stringprep-based definition (which nobody implemented) to one which the receiver SHOULD (not MUST) check for UTF8 conformance.  This means that RFC3530bis and RFC5661 are different, but that the difference is due to RFC5661 matching RFC3530 in referring to something that was not and should not have been implemented.  So the different names show that something different is referred to and a look at RFC3530bis will explain that that change as reflecting the need to describe implementations as they are. 

I think this relates to the discussion of how to propagate internationalization changes in RFC3530bis to v4.1.  We have discussed doing this as a separate document.  I think the implication of my interpretation of Mike's rule is that if did that, we should do an RFC5662bis at the same time to propagate the string type definition changes, so name change and referent change go together.