Subject: RE: [nfsv4] Notification delays

From: "Khan, Saadia" <[email-masked]>
Date: Mon, 23 Jan 2006 12:30:22 -0800

-----Original Message-----
From: david m. richter [mailto:[email-masked]] 
Sent: Friday, January 20, 2006 1:04 PM
To: [email-masked]
Subject: [nfsv4] Notification delays

	hello,

	I've a couple small questions about notification delays in
section
6.3 in the draft.  First, Saadia's original proposal named them
"child_attr_delay" and "dir_attr_delay"; in the draft they're
cryptically called "supp_child_attr_notice" and "supp_dir_attr_notice".
I propose "dir_notif_delay" and "dir_entry_notif_delay"  (or
"dir_attr_notif_delay",
etc) for clarity.

>> fine by me if that helps clarify them.

	Second, I'm curious about the type of those arguments.  Saadia's
original proposal has them as nfstime4, which seems to be realized as
struct timespec.  I wonder what people think of instead using an integer
type in units of seconds.  Is that too coarse, relative to a client's
RTT?
Having nanosecond or microsecond precision seems overmuch -- but maybe
it could possibly be important for a client to get notified at 2 or 3
RTTs..?
Would a server want to be able to commit to subsecond delays?  Would
that even help at all with the large-slowly-changing-directories use
case?

	thanks,

	d
	.

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

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