RE: [nfsv4] The state of directory delegations

["Khan, Saadia" <[e-mail]>]

> -----Original Message-----
> From: Noveck, Dave 
> Sent: Friday, September 09, 2005 11:53 AM
> To: [e-mail]
> Subject: [nfsv4] The state of directory delegations
> 
> 
> 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.

Sounds like a reasonable suggestion. I am ok with making that change.

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

After talking to Tom Talpey, I believe we decided that using the
SEQUENCE op should be the way to go here. That would make the proposal
independent of sessions. However I do believe that currently the draft
does not go into too much detail on how to use that. As you mentioned,
that can be fixed.

> 
> 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?

Since we've had consensus already that dir dlgs should be independent of
sessions maybe we will have to add some kind of sequencing mechanism
here. I'm not sure how complex that change will be and how useful it
will turn out. On the other hand we might have to reconsider dependency
on sessions.

Saadia

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

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