Subject: RE: changes to nfs4_prot.x / protocol description

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 4 Oct 2001 13:40:36 -0700

Spencer Shepler wrote:
> I have updated the protocol description file.  The changes reflect the
> issues list and specifically those that seemed to be the most
> straightforward or those that were needed in the near term.  I have
> include the list of issues that are reflected in the changes and a
> brief description of what was modified.
>
> I have also included the updated .x file.  I will post this and
> context diffs on www.nfsv4.org sometime tomorrow (Wednesday).

I didn't see this there.  Have I just missed it?

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 4 Oct 2001 18:11:43 -0500

> I didn't see this there.  Have I just missed it?

Thanks for the reminder.

I have posted the new nfs4_prot.x (which includes changes to address
the two items Dave just pointed out).  It is located at:

http://www.nfsv4.org/rfc3010updates/nfs4_prot.x (version 1.101)

I have also updated the issues list with more items.  It is located at:
http://www.nfsv4.org/rfc3010updates/issues.html (version 1.4)

The addition items that were included are:

*Issue136:
Clarify operations (SETATTR/GETATTR) appropriate for named attribute
directory (as returned by OPENATTR) and the effects of SETATTR on named
attribute files (limited attribute support possible).

*Issue137:
OPEN does not list NFS4ERR_EXPIRED as valid error. OPEN must return
NFS4ERR_EXPIRED if the lease has lapsed for the client. Otherwise the client
will be misled about lease expiration with respect to other state held at
the client.

*Issue138:
Is the filehandle type changeable by the server? Is it possible for the
server to switch from persistent to volatile filehandles on an
administrative action? For example, can the re-exporting of a directory
change the filehandle type based on export options provided by an
implementation. If so, client recover from such events may be very
difficult.

*Issue139:
When a client recovers and the "change" attribute has changed for a file and
the client holds modified pages for that file are the following recovery
actions acceptable for a client implementation:

*if the client had a write delegation for the file, mark the file as
unusable
*if the client did not have a write delegation and did not have any locks,
(try to) write back the dirty pages and flush the cache
*if the client didn't have a write delegation but did have locks, mark the
file as unusable

*Issue140:
In the case of client recovery, are there any other attributes that the
client should inspect when reopening a file

*Issue141:
Are there issues with respect to directory entry ordering requirements for
replication and migration to work properly. For example, if the directory
ordering changes on a migration event, the client may not be able to
continue from READDIR operations that have not fully read a directory.

*Issue142:
Clarify the server's ability to change its lease period at server restart
and the fact that the server must have a grace period that is at least as
long as the lease period used in the server's prior instantiation. Clients
should therefore obtain the lease period at each server restart.

*Issue143:
Migration identification; relies on stateid; is it important for filesystems
for which there is no state held.

*Issue144:
Need further definition of clientaddr4 struct members. Specifically r_netid
and r_addr from:

struct clientaddr4 {
    /* see struct rpcb in RFC 1833 */
    string r_netid<>; /* network id */
    string r_addr<>; /* universal address */
};

*Issue145:
Callback identification relies on the client identifying itself and the use
of a separate communication channel. This approach can result in callback
paths that are not functional when a NAT or firewall is in place between the
client and server. Should the RPC channel established by the client be used
by the server for callbacks?

--

- Spencer -

---

From: "Sergey Klyushin" <[email-masked]>
Date: Fri, 5 Oct 2001 10:10:05 -0400

> -----Original Message-----
    > From: Noveck, Dave [mailto:[email-masked]]
    > Sent: Thursday, October 04, 2001 4:41 PM
    > To: [email-masked]'; [email-masked]
    > Subject: RE: changes to nfs4_prot.x / protocol description
    >
    >
    > Spencer Shepler wrote:
Where is description of new OPEN/LOCK model? I can not find it on
http://www.nfsv4.org/rfc3010updates/index.html.
Looking email list I found only one Spencer's email about new model.
Is there more detailed specification?
Thanks,
Sergey

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Fri, 5 Oct 2001 14:51:09 -0400 (EDT)

According to the update, stateid4's are now defined as:

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

Assumption: 'seqid' does not refer to the seqid associated with the
nfs4_lockowner, but refers to the (formerly opaque) portion of the
stateid which is mutated on open/close/lock.

If this is correct, why was it decided to expose this part of the
stateid to the client?  I would actually prefer to have stateid's
be completely opaque (typedef opaque stateid4[16]) for two reasons:

1.  Delegation stateid's do not mutate, and therefore have no
associated seqid field.
2.  It seems more natural, given that stateids 0 and -1 have special
semantics (as pointed out by Dan from Hummingbird).

Is there some reason that I'm missing for making the "stateid seqid"
visible to the client?

Kendrick

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 5 Oct 2001 16:05:04 -0500

> Is there more detailed specification?

My email of a awhile back is the only text description of the ideas
behind the new model and the updated .x at this point.  I will work
over the weekend to come up with a reasonably short but full
description of how a client and server should use the new data structs
and interact with one another.  We can then use that (in expanded
form) for updates to RFC3010 proper.

-- 

- Spencer -

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 9 Oct 2001 13:53:01 -0400

1. What stateid is used in READ and WRITE requests? open_stateid or
lock_stateid?
2. Do we need verifier in OPENres? Why stateid is not enough?

Sergey

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Tue, 9 Oct 2001 18:36:18 -0400 (EDT)

Questions:

(1) Suppose that one or more lock stateids are derived from
an open stateid with the new LOCK operation, then the original
OPEN is CLOSEd.  Does this also "close" the derived lock stateids?

(2) Consider this scenario with three lockowners L1, L2, L3.
Initially L1 has a file open with (open) stateid A, and L2 has
the same file open with (open) stateid B.  The new LOCK operation
is used to derive lock stateid C, for lockowner L3, from open
stateid A.  The client then attempts to use the LOCK operation
again to derive a new lock stateid, for lockowner L3, from open
stateid B.  Does this:
  (a) succeed, and instantiate new lock stateid D, which will
      be independent from lock stateid C,
  (b) succeed, but not instantiate a new lock stateid (the
      server would return an updated version of stateid C), or
  (c) fail with an error?

- k

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 10 Oct 2001 10:27:43 -0500

> OPEN is CLOSEd.  Does this also "close" the derived lock stateids?

Yes. Similar with the old state model where the close represents the
client's "release" of that state stream.

>       server would return an updated version of stateid C), or

(a) is the right answer.  So in the case of a Posix client that is
able to open() a file more than once and then do file locking on those
separate file descriptors and not have the lock conflict, the client
needs to use the same open_owner for all opens of the same file.  This
way the lockowner will be assigned appropriately.

I think this is the right approach in that we don't want to overlay
too much of the Posix semantics onto the protocol's model of
open_owner and lock_owner such that choice (b) would made.  (a) is
good, (b) and (c) are bad. :-)

-- 

- Spencer -

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Wed, 10 Oct 2001 12:27:24 -0400 (EDT)

> way the lockowner will be assigned appropriately.

I don't understand what this means.  It sounds like you are saying that,
in scenario (a) described above, locks placed using the new lock stateid D
would conflict with locks placed using the old lock stateid C (even though
the associated lockowner is the same in both cases).  In other words, the
lock stateid is the unit of lock contention (I had assumed it would be the
lockowner).  Is this correct, or would locks set using lock stateid C be
indistinguishable from locks placed using lock stateid D?

- k