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