Subject: RE: [nfsv4] Review Comments for The 4th Review Meeting for Locking and Directory Delegations

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 25 Oct 2007 13:20:27 -0400

> 26901-26903  Mike            Needs clarification  

> 26901	   The server MUST send in cpda_delegation a delegation
corresponding to
> 26902	   the type of what the client requested in the OPEN,
WANT_DELEGATION,
> 26903	   or GET_DIR_DELEGATION request.

I recall that we had a discussion about whether CB_PUSH_DELEG could in
fact
propagate a delegation requested by GET_DIR_DELEGATION, as opposed to
delegation
for non-directory types of objects.  I guess there was also implicitly a
question
about whether it should be able to do so.

So on the first point, the answer seems to be "No" since
CB_PUSH_DELEGargs
contains an open_delegation4, which doesn't have a provision for a lot
of the
data returned in a GET_DIR_DELEGATION4resok.  Since this information is
not
provided on the response to the GET_DIR_DELEGATION or in the
CB_PUSH_DELEG,
it doesn't seem that there is a current provision for CB_PUSH_DELEG to 
deliver a directory delegation.

In fact, there is no provision currently for GET_DIR_DELEGATION to
promise
to deliver a directory delegation when the delgation is available (i.e.
there
is no conflict on that specific object), which would call for
CB_PUSH_DELEG
or something like it.  The only provision in which it promises to signal
you
is when there is resources unavailable, i.e. something will be resolved
by
CB_RECALLABLE_OBJ_AVAIL. 

I'm supposing that this structure derives from the fact that there are
no
write directory delegations and it is thus impossible for there to be a 
hard conflict that would not allow a directory delegation to be granted.
I'm not sure if this logic is valid since it is possible for a server
not
to grant a directory delegation because frequent directory changes makes
this not an efficient way to go.  And if that could cause a delegation
to be denied, the situation might be changed when those changes stop.

Anyway, what I am going to do now is to change CB_PUSH_DELEG so it
doens't
reference GET_DIR_DELEGATION and if we want to extend GET_DIR_DELEGATION

and CB_PUSH_DELEG to support this, we can handle that separately from
the
review of the locking chapters.

-----Original Message-----
From: Weaver, Amy 
Sent: Friday, September 14, 2007 5:38 PM
To: Eisler, Michael; Noveck, Dave; [email-masked];
[email-masked]; [email-masked]
Cc: Weaver, Amy; Erasani, Pranoop
Subject: [nfsv4] Review Comments for The 4th Review Meeting for Locking
and Directory Delegations

What: The 4th Review Meeting for Locking and Directory Delegations

When: September 14, 2007, 12:00 - 2:00 PST

Attendees and roles:
Name             Company                     Role
------------------------------------------------------------------
Mike Eisler	     Network Appliance           Reader/Editor
Dave Noveck	     Network Appliance           Editor
Amy Weaver       Network Appliance           Recorder
Spencer Sheple   Sun Microsystems            Editor
Robert Gordon    Sun Microsystems	         Editor/Inspector 
Eric Kustarz     Sun Microsystems	         Editor/Inspector 

Items/lines to be reviewed:
          Directory Notification Attributes
          6057-6079

          CB_NOTIFY
          CB_PUSH_DELEG
          CB_RECALL_ANY
          CB_RECALLABLE_OBJ_ANY
          26670-27121

          CB_WANTS_CANCELLED
          CB_NOTIFY_LOCK
          27340-27452 

Review Comments:
Line#        Raised by       Comment 
-----        ---------       --------- 
6060         Amy 	           add "to" after free
6064 - 6066  Mike/Dave       Remove "^M", clarify whether server is free
to return result 
                             which is in conflict what getattr returns
6069, 6071   Amy             dir_notif_delay and dir_notify_delay
inconsistent
26740-26753  Mike            Change to bitmap
26740-26753  Dave            Why? Similar attributes uses bit map, for
extensibility
                             without extending the union
26758        Mike            notify4 has to be a bit map
26782        Mike            Describe pNFS mapping as well
26815        Mike/Dave       Do we want to distinguish between
renaming/removing a file across directories
                             Creating a hard link is considered adding a
file, should be discussed in
                             Adding a file.  Question: distinguish
between creating a hard link vs. a file
26831        Mike            Clarify that this is get_dir_delegation
26835        Mike            any file -> any file's
26837        Mike            per file -> a specific file
26854        Mike            Delete 20.4.5
26857        Mike            Add one line summary
26898        Dave/Robert     Want to have specific error to reject
delegation, for all other error codes,
                             the inspection team has to meet to define
the action for each error as what 
                             to do with this delegation.  If permanently
rejected the delegation, the 
                             WANT in WANT_DELEGATION is permanently
deleted by the server.    
26901-26903  Mike            Needs clarification  
26911-26913  Mike            To be deleted.
27007        Mike            sixteen -> number of
27068-27077  Mike/Dave       Move under implementation
27081        Mike            One line summary
27085        Mike            Actual synopsis
27115-27120  Mike/Dave       1. objects to keep -> something else
                             2. Argument means that the client will be
allowed to request that many objects 
27122-27124  Mike            Delete implementation
27341        Mike            One line summary
27344        Mike            Synopsis completely wrong   
27373        Amy             Add "to" in front of grant
27338        Mike            Implementation - how to deal with races
between this operation and operation on the fore 
                             channel that asks for delegations or
layouts
27392        Mike            One line summary
27400-27401  Mike/Dave       Reverse the arguments order
27414        Mike/Dave       may -> can
27415        Mike/Dave       may -> might be available
27426        Mike/Dave       must not -> MUST NOT
27427        Mike            lock -> LOCK
27412        Mike            Needs to clarify that the client must
previously issued unsuccessful lock operation
27434        Mike            Requires cross reference
27445,27446  Mike            "must not" -> "MUST NOT"
27448        Amy/Mike        "should" -> "SHOULD" or "MUST"  
27452        Mike            add "to" before poll
27448-27452  Mike/Dave       Add the following:
                             In the event of OPEN_UPGRADE, if the value
of may notify flag changes,
                             then the last result wins.
             Spencer         Move to the description at line 27423

Regards,
Amy Weaver [email-masked]
408.822.1532

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

---

From: Robert Gordon <[email-masked]>
Date: Thu, 25 Oct 2007 13:42:15 -0500

On Oct 25, 2007, at 12:20 PM, Noveck, Dave wrote:

> doesn't reference GET_DIR_DELEGATION and if we want to extend  
> GET_DIR_DELEGATION
> the review of the locking chapters.

I agree.

We might want to consider renaming CB_PUSH_DELEG to CB_PUSH_FILE_DELEG.

Robert.