RE: [nfsv4] Directory delegations, take 2

[clip]
> Anothedr way of putting it is that what we have
>been calling a "recall" is just a change notification on all
>entries.

The difference is that a notification leaves the directory
delegated while a recall does not.

It will be nice to have a notification for the whole directory,
but I think the server must have a way to recall the delegation.
For example, when it needs to recycle resources.

- Benny

>-----Original Message-----
>From: David Robinson [mailto:David.Robinson@sun.com]
>Sent: Monday, October 27, 2003 11:13 PM
>To: nfsv4@ietf.org
>Subject: Re: [nfsv4] Directory delegations, take 2
>
>
>[Catching up on last week's thread...]
>
>Directory delegations in this round should be read-only.
>
>Why allow no seatbelts? My point was that with a delegation
>a client knows the state of its consistency, when asking
>for a delegation but ignoring the callback it knows when
>its cache is consistent and when it won't be. Without a delegation
>it has no way of knowing. Bottom line, this becomes a client
>quality of implementation issue, not a protocol issue so we can
>ignore it as a rant on my part.
>
>In recall versus change notification, with a read-only delegation
>a recall operation in the sense of a delegation is just a notification
>that the directory has changed as there is no data that will
>ever need to be written back, at worst it is just a cache flush
>notification. Anothedr way of putting it is that what we have
>been calling a "recall" is just a change notification on all
>entries. As one approach, we could design this so that we
>allow a change notification operation that takes a directory
>and a list of cookies, one for each entry that changed.  Then
>have the special zero cookie indicate all entries changed as
>an optimized method.
>
>Sync vs async, the issue is not timeliness, in both cases it is
>hard to guarentee timeliness.  But as Dave pointed out, the
>primary advantage of sync is in allowing ordering of operations.
>We MUST have sync notifications, but it may be useful to have
>on acquistion of a delegation the client specify if it wants
>sync or async notifications.  Some clients may not be able to do
>anything better with a sync notification so they may not want to
>impose a burden, while others may need it for interesting applications.
>
>Directory operations must be written through, there is no point in
>requiring the client to re-read what it just wrote or for a
>server to callback to the client that sent it the change, the client
>knows the current state.
>
>I understand the performance impact of not including the attributes
>into the delegation.  My major concern is in the area of scaleability.
>Currently in most Unix systems, data and metadata operations on a file
>require no locks or interactions with any other file, it is highly
>scaleable. Likewise naming operations only involve the directory
>involved and do not require locks on component files.  Tying the two
>could involve coordinating a large number of locks which will
>negatively effect scalability.  If we keep attribute delegation
>separate and allow per entry change notification, the impact of
>a directory changing will be modest and the change of a file's
>attributes would not ripple through other files.
>
>	-David
>
>
>
>_______________________________________________
>nfsv4 mailing list
>nfsv4@ietf.org
>https://www1.ietf.org/mailman/listinfo/nfsv4
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4