Subject: [nfsv4] directory delegation/notification for v4.1 -- scope

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Sep 2003 06:52:54 -0700

One of the items that has been discussed as a possible extension for
the current v4 minor version is some form of directory delegation. 
I've been thinking a bit about what the right scope for this is in the
context of v4.1, sometimes veering wildly between the protocol extension
minimalism of "Let's do the smallest possible thing and leave the
interesting stuff for v4.2" all the way up to "Maybe directory write
delegation isn't all *that* bad".

Regardless of what the official schedule for v4.1 is supposed to be (I
haven't looked recently and I suspect nobody else has either), I do think
it is time to get serious about defining the scope of v4.1.  There's a
lot of very interesting stuff already on the table which we don't want
to hold up indefinitely waiting for things like directory delegation
to become less formless.

This note is an attempt to put a stake in the ground defining what I think
is a reasonable range of features to put under the directory delegation
heading for v4.1.  I'm sending it out now mainly so that people on the
list who are attending this week's NFS Industry Conference will have an 
opportunity to grab me, ask "Are you freakin' crazy?" and explain their
concerns.  I'll try to summarize the discussion for the working group,
shorn of irrelevant insults (Yes, that does imply I will carefully preserve
the relevant insults :-)

Anyway, here are the high-level bullet points that define what I think makes
sense to do for now.  To help give some substance to this discussion some
protocol details are mentioned.  I'm sure these are still quite buggy, but 
that's not the main thing right now.  I'd like the discussion to focus on 
the value (or lack thereof) of the feature set and what can be done to improve 
that, while not biting off more than we can get done for v4.1.

Basic feature is directory notification:

      Explicitly requested by client.

      Server prerogative to grant or not.

      Response contains directory contents plus a stateid.

      Client promises not to change directory or attributes of any of the
      files (exception for access time).

      Server notifies client, via callback path, of any changes to the 
      directory or attributes of files within (again, exception for
      access time.

      Client notified when file is opened for write.  No attribute
      updates while file is opened for write.  When file closed,
      nootification contains new attributes.

      Notifications happen asynchronously.  They don't require that the
      client acknowledge to allow the change to proceed.

      Server may recall notification if sending updates gets too onerous
      (or for any other reason).

Additional option is read delegation:

      Requested, as an option, with directory notification request.

      Server may choose to grant or not.  Client may get back OK on the
      notification but the delegation is refused.

      Equivalent of read delegation on all files in the directory.

      Recalled by server when name change of existing file, deletion of
      existing file, or open for write or open denying read.

      Clients must respond to recall before conflicting operation.

Second additional option is restricted read delegation:

      Requested, as an option, with directory notification request.

      Server may choose to grant or not.  Client may get back OK on the
      notification but the delegation is refused.

      Similar to above but more restricted, and designed to be useful
      for those not using deny modes.

      Server will not grant if its semantics do not allow name-change/
      remove while file is open.

      Client may open files in directory (for read only with nothing 
      denied) without contact server.

      Recalled by server when any file in directory open with read or
      write denied.

      Clients must respond to recall before conflicting operation.

      When file opened for write on the server, clients notified 
      asynchronously (as part of basic directory notification).

Comments appreciated.  Those of the form "That's exactly right" most
appreciated :-)

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

---

From: David Robinson <[email-masked]>
Date: Thu, 25 Sep 2003 16:32:47 -0500

I am having trouble understanding what the implications
of having a directory delegation are.

In one model, a directory is just a file that is read with
READDIR, OPEN, LOOKUP and written with CREATE and RENAME.
Attribute operations and other than the LOOKUP portion
of an OPEN would be impacted by a delegation. If a write
delegation is held the OPEN would block pending any
changes get flushed, but a read delegation would allow
any OPEN to succeed.

The alternative model is that a directory delegation
controls all aspects of file access that is not covered
by the existing delegation. Then it will matter if someone
opens a file for WRITE because the attributes will change
and recalls may be needed.

 From my perspective there is delegation of three different
aspects of a filesystem: the contents of a file, the attributes
or a file, and the name of a file. Intertwining the last two
will probably be complex and probably unnecessary.

So specifically in your proposal, I would remove the requirement
that a client not change the attributes of a file.

But I would encourage an attribute delegation, but leaving the
mtime/atime and size attributes as part of the existing delegation.

	-David

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 26 Sep 2003 12:20:31 -0700

Noveck, Dave wrote:

> it is time to get serious about defining the scope of v4.1.

I agree.  Don't look for an official schedule, since there isn;t
one :-)  Have the WG chairs talked themselves or pinged our AD
about how to proceed with minor versioning?

>       Response contains directory contents plus a stateid.

Looks OK.

>       files (exception for access time).

I think the client should be welcome to make changes, as your
exchange with Saadia seemed to be leading.  It could receive
notifications about the changes or not.

>       directory or attributes of files within (again, exception for

Do we really want the directory notification to extend to the
attributes of the files within?  This will be a pain to implement,
and I'd expected the real value of directory notification to be
about being able to see CREATE and DELETE ops which change the
list of the directory's contents.  I know Windows Explorer might
like to notice such changes, but I note that in that environment,
I see a new file appear with a length of zero, and have to click
'refresh' to see the real length after the file is written and
closed.

>       (or for any other reason).

Looks OK.

>       Equivalent of read delegation on all files in the directory.

See comments above, otherwise this looks OK.

>       asynchronously (as part of basic directory notification).

This looks OK.

Rob T