Subject: [nfsv4] Conference call -- directory delegations

From: "david m. richter" <[email-masked]>
Date: Thu, 19 Jan 2006 16:49:52 -0500 (EST)

Hello, I'd like to follow-up on the points raised about directory
delegations.  Chiefly, I'm interested in the discussion of separating
dir. delegations from notifications.

	At CITI, Trond made a good point for separating them: if it turns
out that notifications don't work well or aren't enough of a "win",
keeping open the possibility of dropping them in a future minor version
would be important.  Eliding dir. delegations and notifications in a
single operation would prevent this.

	I also have some concern about the increased complexity of
implementation and server state coming from an untested(?) proposal,
particularly since we know for sure that delegations alone will provide
significant gains.  Exposing notifications to a userland API, e.g., would
increase their utility, but I'm taken to believe that's not intended.

	As such, I am curious what everyone's feelings are about
separating the two.  We could introduce a separate operation,
REQUEST_NOTIFICATION (whatever), that would implement Saadia's
notification scheme.  That operation could depend on the client already
possessing a delegation on the directory in question.  Notifications could
still implicitly end when the delegation is recalled.

	Given that the client would have to probe for delegation and
notification capabilities on the server anyway, it seems to me that
having two separate operations, with two separate (though related)
purposes and sets of arguments and implementation details, would have a
higher conceptual integrity than the current draft proposal.  Put another
way, can anyone present a case for _not_ separating them?

	Please, align your crosshairs and have-at.

	thanks,

	d
	.

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

---

From: Mike Eisler <[email-masked]>
Date: Thu, 19 Jan 2006 14:38:08 -0800 (PST)

> implementation and server state coming from an untested(?) proposal,

Most of the current NFSv4.1 draft is untested. If delegations
worry you, how do you feel about the recovery issues with
parallel NFS? :-)

> increase their utility, but I'm taken to believe that's not intended.

True. To me the utility in notifications is to
prevent re-READDIRs of directories that change
slightly. The fact that
at least one NFSv3 client has an option to enable or disable
READDIR plus says it all, and sometimes I run into
situations where it would be nice to turn READDIR plus off.

Do all client implementors feel they have a good handle
on when to issue READDIRs that fetch per directory
entry attributes and when to issue READDIRs that do
not fetch attributes? Do tell.

> Put another

>From the I-D:

"If a client asks for
   notification for a certain event, the server will notify the client
   when that event occurs. This will not result in the delegation being
   recalled for that client. "

Thus as currently specified, notifications bind with delegations,
and modify delegation recall behavior.

One could have two separate operations, but unless one
wanted multiple round trips, the SET_NOTIFICATION 
operation would have to live in the same COMPOUND immediately
following the GET_DIR_DELEGATION operation. That can be even
more complex to implement.

If you are arguing for two completely separate operations,
such that a client that had a notification for an event type
set and could lose its delegation for that event type, then
I think the utility of notifications is sharply diminished.
It also increases the amount of state required to obtain
both a delegation and notification for a file.

As Saadia pointed out in the conf call, servers and clients
don't have implement the notification aspect. On the flip
side, if no client is going to implement them (perhaps
because the clients have optimized the readdir vs. readdir_plus
decision algorithm), that's an argument for dropping them.
But if they are ever added later, it will be have to be as a
replacement operation.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 19 Jan 2006 18:16:59 -0600

> situations where it would be nice to turn READDIR plus off.

To David's original question of intended use of notifications, I believe
we have concensus that building something that can effectively be used
for a user-level API is beyond the scope of what the WG is interested
in at this point.  Not to say that it isn't out of scope in the future
but for 4.1 it is...

Effective utilization of READDIR with and without attributes is
important since NFSv4's attribute set is rich and somewhat
expensive to obtain.

> not fetch attributes? Do tell.

The Solaris client is less than optimal in its management of 
READDIR/READDIRPLUS usage and does a reasonable job but more
help would certainly be worthwhile.

Spencer