[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nfsv4] Directory delegation modification



> It seems that the protocol does not specify if an 
> already established directory delegation may be 
> modified. So, it would be beneficial if we agree 
> on how the server SHOULD/MUST process an attempted 
> modification.

See section 10.9.2.  

Reading it, it does seem that it could be clarified/re-organized a
little but I think all of the issues are dealt with.  Fundamentally,
directory delegations are read-only, but we have an associated
asynchronous notification mechanism to allow environments in which
delegations would always be recalled to be handled better.

The penultimate paragraph does deal with an optimization in the case in
which only one client has a delegation.  In this case the server can
allow changes initiated by that client without a recall.

Maybe I'm not understanding your question.  Could you be a little bit
more specific about what sequence of operations you don't think is
addressed by the spec.

-----Original Message-----
From: Anatoly Pinchuk [mailto:apinchuk at bluearc.com] 
Sent: Tuesday, October 13, 2009 12:43 AM
To: nfsv4 at ietf.org
Subject: [nfsv4] Directory delegation modification


It seems that the protocol does not specify if an already established
directory delegation may be modified. So, it would be beneficial if we
agree on how the server SHOULD/MUST process an attempted modification.
Two possible approaches are:
- Disallow the modification and return an error code if the client tries
to modify the delegation
- Allow the modification and replace all existing delegation fields with
new ones constructed using GET_DIR_DELEGATION arguments
Has anyone considered this issue?

Regards,
Anatoly
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4