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

From: "Khan, Saadia" <[email-masked]>
Date: Wed, 24 Sep 2003 16:00:52 -0700

A few comments and questions.

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).

>> what if the client holding the notification wants to open the file
for writing or issues a conflicting request? 
Should the client be required to return the notification or should the
server after receiving the request from that client remove it from its
directory notification list of hosts? 
Or does that not affect the notification and that host gets notified
along with others that this particular file has changed.

      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).

>> What about server reboots and reclaims of dir delegations?

Saadia

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

_______________________________________________
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: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Sep 2003 19:24:54 -0700

the

Saadia wrote:
> what if the client holding the notification wants to open the file for
writing or 
> issues a conflicting request? 
server after 
> receiving the request from that client remove it from its directory
notification list 
> of hosts? 
along with others 
> that this particular file has changed.

I think you are really showing that my statement above is wrong.  I
think I was drawing
an inappropriate analogy with file read delegation in which it is
important that, when
read delegation is in effect, nobody can modify the file, since any such
modification
would invalidate the cached copy that other clients hold.  In the
directory notification
case, other clients are prepared to receive notifications about changes
made by clients not
holding directory notifications on the target directory and there is no
special reason
that they can't deal with changes made by a client getting notifications
on that directory,
since all changes are mediated by the server.

You could notify the client making the change just as all others
tracking the directory,
but given the session extensions, I think you would be in a position to
know that a change 
was made by the same session as the one requesting notification and
could thus simply
avoid sending these.  A client is presumed to know about changes he
makes himself.

The situation is a little more complicated when read delegation or
restricted read
delegation is in effect for the directory and an inconsistent open is
done.  However, I
still think you can avoid recalling your own delegation when yours is
the only inconsistent
open.  At least I'd like to spec things out on that basis and see how
bad the problems 
are.   

-----Original Message-----
From: Khan, Saadia 
Sent: Wednesday, September 24, 2003 7:01 PM
To: Noveck, Dave; [email-masked]
Subject: RE: [nfsv4] directory delegation/notification for v4.1 -- scope

Saadia

---

From: "Khan, Saadia" <[email-masked]>
Date: Fri, 26 Sep 2003 11:28:24 -0700

> From: Noveck, Dave 
> Sent: Wednesday, September 24, 2003 7:25 PM
> To: Khan, Saadia; [email-masked]'
> >      Client promises not to change directory or attributes 
> of any of the
> > Should the client be required to return the notification or 
> should the server after 
> > receiving the request from that client remove it from its 
> > Or does that not affect the notification and that host gets 
> notified along with others 
> I think you are really showing that my statement above is 
> wrong.  I think I was drawing an inappropriate analogy with 
> file read delegation in which it is important that, when read 
> delegation is in effect, nobody can modify the file, since 
> any such modification would invalidate the cached copy that 
> other clients hold.  In the directory notification case, 
> other clients are prepared to receive notifications about 
> changes made by clients not holding directory notifications 
> on the target directory and there is no special reason that 
> they can't deal with changes made by a client getting 
> notifications on that directory, since all changes are 
> mediated by the server.
> 
> You could notify the client making the change just as all 
> others tracking the directory, but given the session 
> extensions, I think you would be in a position to know that a change 
> was made by the same session as the one requesting 
> notification and could thus simply avoid sending these.  A 
> client is presumed to know about changes he makes himself.
> 
> The situation is a little more complicated when read 
> delegation or restricted read delegation is in effect for the 
> directory and an inconsistent open is done.  However, I still 
> think you can avoid recalling your own delegation when yours 
> is the only inconsistent open.  At least I'd like to spec 
> things out on that basis and see how bad the problems 
> are.   
> 

In addition to that there should be a mechanism, even in the
notification case that would take care of recalling and giving back the
notification. Something like the callback for delegations.

I also mentioned in my last email the need to add some reclaim logic for
directory delegations, so on a server reboot, the client should be able
to reclaim its directory read delegations back. That can probably be
added to the operation used for getting the directory delegation in the
first place.

Saadia