Re: [nfsv4] Directory delegations, take 2

[Ted Anderson <[e-mail]>]

On 10/21/2003 16:41, David Robinson wrote:
 > I will claim that one of the set of requirements that we are trying to
 > solve is the ability of a client to cache the contents of a directory
 > (the names and file handles) in order to efficiently operate on part
 > of the namespace tree.

Yes, and not just efficiently, but with well-defined semantics.

 > I will argue that the ability for a client to modify a directory
 > without going to the server is not a requirement.  For all the
 > arguments laid out by Dave, it will be difficult to handle not only
 > the error semantics, but it would imply that the client should have a
 > reasonable ability to determine what the new cookies should be,
 > otherwise we take the rare problem of invalid cookies and make it the
 > common case.

I even agree with this.  I think in the long run, providing very high
scalability and client performance will require write delegation of
directories, but there are significant complications.  So putting this
off makes sense.

 > I would support read-only delegations of directory contents.  All
 > directory modifying operations MUST we written through to the server
 > and any client having a delegation MUST be notified.  [...]  I agree
 > that the delegation recall (effectively change notification) should be
 > synchronous. ...

Yes.  I think this would be sufficient to provide very useful semantics
to clients.  Anything less than synchronous notifications leads to
update semantics that whose specification is too fuzzy to be very
useful.  Asynchronous notification avoids polling and the performance
problems associated with that approach.  But when you consider delivery
delays, there is essentially no improvement over the traditional
time-based approach WRT consistency semantics.  Making the notifications
synchronous provides are qualitative improvement in the protocol.

On 10/22/2003 12:58, Nicolas Williams wrote:
 > Synchronous notification delegations sound both neat and like trouble.
 > If we can't guarantee synchronicity (and from these arguments it's
 > clear that we shouldn't), what good is it to provide synchronous
 > notification delegations?  Applications will not be able to use the
 > notification mechanism for synchronization without the guarantee, so
 > why would they want synchronous notifications?

Nico wades in on the other side, due to concern about failures.  My
counter argument is that failures can be handled effectively while
preserving the benefits synchronicity provides.

It is certainly possible to make the notification timeout smaller for
read delegations than for write delegations.  Bounding the time required
to send back cached updates is hard for write delegations, but easy for
read delegations, which require relatively small amounts of work on the
client.  The important aspect of the timeout, however small it is made,
is to ensure that it is tied to the lease interval.  In this way the
client always knows when the server might have failed to deliver a
delegation related message.  This has the big advantage that consistency
semantics are preserved as long as there are no failures of this sort.
These failure events can be delivered to highly paranoid applications or
can be considered after the fact when debugging application problems.


There are still interesting issues to debate.  I like the idea of
delivering notifications which include a description of the directory
update so that delegations do not have to be recalled.  It seems to have
large performance benefits in the common case of low-flux updates.
However, Nico's discussion of "directories as databases" is germane.

The topic of granularity is also very interesting and important.  Should
a directory delegation apply to its contents only or also the attributes
of its children?  Since a file delegation can protect file attributes,
extending directory delegation to its children is not strictly necessary
from a functional point of view.  However, the benefits of reducing the
state management burden are not to be overlooked.  Once you consider
children, it is tempting to allow entire subtrees as well (again,
hardlinks rear their ugly heads here).  A delegation on an entire file
system would also be a very nice feature for when the update-flux is low
enough, as it often is.

I am mindful of the complexity and timing concerns of addressing all
these additional issues.  At a minimum, I think read directory
delegation with synchronous recall is necessary to provide a useful
increment in functionality over NFSv4.0.

Ted Anderson


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