[nfsv4] The state of directory delegations

["Noveck, Dave" <[e-mail]>]

I have heard that at the Paris IETF there was some concern/uncertainty 
about the state of directory delegations with respect to v4.1.  As a
result I've spent some time reading documents, looking at the mailing
list archive, talking to people, getting myself totally confused, and
then getting myself unconfused, I hope.  So this note is an attempt
to clarify the situation and begin the discussion of remaining issues
with regard to directory delegations.

So given that there have been two proposals for this, I had been a 
little unclear (and sometimes more than a little unclear) about where 
we had consensus and where we didn't.  I'll get to the details in a bit 
but the overall message is that we have consensus on most of the issues
but that we still have to address one significant issue, the proper
relationship between directory delegations and notifications.  Also, 
in reviewing the documents there are a few minor issues that need to 
be resolved.  I don't think any part of this should hold up the first 
rollup draft for 4.1.

Anyway, the two proposals are:

     draft-ietf-nfsv4-directory-delegation-01.txt

     draft-wickman-nfsv4-directory-delegations-00.txt

I'll refer to these below, based on the diffs of the titles as 
ietf-01 and wickman-00 (even though they really should be ietf1 
and wickmans0 :-).  

The three substantive differnces are:

1) Write directory delegations (in wickman-00 only).

2) (asynchronous) Notifications (in ietf-01 only).

3) CB_RECALL_ANY (in ietf-01 only).

So there was discussion of most of these in a mail thread 4/18-19,
and I think the clear consensus of the discussion was that write 
directory delegations are not ready for 4.1, and that work should 
go ahead on notifications, based on ietf-01.  There was no explicit 
consensus on CB_RECALL_ANY but my interpretation of this was that 
this was because there was no dispute that it is a good idea.

There was one issue that there was no clear consensus and that was
the proper relationship between notifications and directory delegations.
Saadia argued for the current draft which ties them together in a
particular way, while Brian Wickman argued for them being totally 
separate.  (I'm interpreting the lack of further discussion on this
point as not due to any sudden agreement).  This is a complicated 
issue that I think needs some further discussion.  I'm going to put 
this aside for now and send a separate message out early next week 
on this topic.

There are a few minor issues that I have noted and that I think should 
be addressed.  The first has to do with CB_RECALL_ANY.  It occurs to me 
that given the possible different ways that servers may structure their 
storage and other resources, it might very well be the case that one 
server is concerned with reducing directory delegations while another 
is concerned with reducing the total number of delegations of all types.

So how about this taking a count and a mask of delegation types to which
it applies (read data delegations, write data delegations, and directory
delegations would each have a mask bit) and the server could ask that 
the count of delegations of any particular class or set of classes
together 
be reduced to that total.  I think it makes sense to merge this with any
analogous facilities for pNFS layouts since it might very well be that
servers might allocate layout state storage and delegation storage from
the same pool and want a client to reduce the total without necessarily 
caring which of those classes bears the brunt of the reduction.

Another remaining issue has to do with sessions.  I believe there has 
been a consensus that directory delegations should not depend on
sessions, so that work on it can proceed independently.  While the
current draft discusses this possibility, the protocol defined in
the draft has not really been modified to reflect that decision.  My 
assumption is that that Saadia can help Spencer make that change as 
part of the work assembling the rollup draft. 

A related issue concerns sequencing of notifications on the callback
channel.  The current draft doesn't seem to address possible sequencing
issues regarding notifications.  My guess is that the assumption is 
that sessions will be present and in that context, if the server (and
the server is the client for callback requests) makes sure that a new
notification for a directory is not issued until a response has been
received for the last, then sequencing is handled properly.  So, if 
this is correct, it raises the issue of whether notifications as well 
as directory delegations need to be independent of sessions.  If not, 
I think all we have to do is make this clear and draft text describing
the sequencing issue.  If not, we have to add some sort of sequencing
mechanism to the notifications.  My off hand reaction is that given 
the fact that pNFS is going to use sessions, the momentum for sessions 
will be strong and it may not be worth the complexity of providing a 
sequencing solution for notifications without sessions.  Other opinions?

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