Subject: Re: Does NFSv4 support file change notification ?

From: Roland Mainz <[email-masked]>
Date: Tue, 25 Jan 2000 20:24:03 +0100

Mike Eisler wrote:

> sortof. nfsv4 has delegations which a client can use to
> force the server to tell when another client wants to make a change.

This doesn't fit in the needs of many applications (example CDE's dtfile
or Win32 explorer, which both fequently POLLs (!!) manually if something
as been changed) which may run on _multiple_ clients.
Best would be a way that the server sends such messages to the
requesting clients if there was a change instead of wasting network
bandwidth with such polls.

For example (no flames, please) the old AmigaDOS 2.0 had such a
functionality. Vertitas has it (according to a note in
news:comp.unix.solaris - which contains a reference to an offical
standard spec - but I can't find the article at DejaNews due lack of
swap space in my brain...), too.
Now we need such a integragration in the network protocols...

One idea would be:
handle = notifyme( whichActions, timeout, notifydelay, filename,
callback, cb_userdata );
whichActions = which actions to watch (read/write/etc.)
timeout = timeout of the notification request, e.g. if the client
doesn't refresh the request after <timeout>, the server deletes it, but
send a "notification timeout" message to the requesting client
filename = (no comment :-)
callback = handler function to call if something changes
cb_userdata = application data passed to the callback

Then we need functions to removeNotification(), verifyNotification()
[check if the server is still OK and knows about it's job to notify the
client] and so on...

Any comments ?

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) [email-masked]
  \__\/\/__/  [email-masked]
  /O /==\ O\  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
 (;O/ \/ \O;) TEL +49 (0) 641/99-13193 FAX +49 (0) 641/99-41359

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 25 Jan 2000 13:51:17 -0600

> bandwidth with such polls.

Are there POSIX file system APIs that provide the type of notification
that you suggest?  If not, then the CDE dtfile example doesn't seem reasonable.
What about the waste of network bandwidth used for the nofiications?

> Now we need such a integragration in the network protocols...

I am not convinced.

> cb_userdata = application data passed to the callback

Callbacks are not guaranteed or required to work for the NFSv4 client
to function properly.  The delegation feature in NFSv4 uses callbacks
but if the server is unable to successfully establish a callback path
to the client, the client continues to function properly but
potentially more slowly.

Therefore, the callback for your notification idea would need to
do the same.  In this case, if the client is unable to obtain the
notification registration, it will return to its polling for change
at the server.  

> [check if the server is still OK and knows about it's job to notify the

In my mind the notification mechanism doesn't scale for the Internet.
There is the potential of having 10s of thousands of clients and each
client may have notification events registered.  Does it make sense
to require the server to notify each of the clients each time
a particular file or directory is written to?

As a practical matter, the NFSv4 specification is currently closed
to new functionality and is going through final reviews on its way
to the IESG (new version NFSv4 draft should be out in a day or two).
NFSv4 does have a minor versioning mechanism.  Therefore, if, at a
later time, notification becomes a hard requirement with reasonably
scalable solutions, the functionality can be added to NFSv4.

> Roland

Spencer

---

From: Guy Harris <[email-masked]>
Date: Tue, 25 Jan 2000 16:57:24 -0800 (PST)

> that you suggest?

None that I know of.  A while ago, I came up with the idea that a
"select()" for an "exception" condition, on a plain file, should return
when the file changes, but I don't know of any implementations of that.

> If not, then the CDE dtfile example doesn't seem reasonable.

"dtfile" is probably just repeatedly "stat()"ting the file.

The Windows explorer, however, is probably using the Win32
change-notification API, and CIFS *does* have a callback mechanism for
that.

> In my mind the notification mechanism doesn't scale for the Internet.

CIFS was originally just Boring Old SMB, which was a LAN protocol; the
SMB change notification mechanism may, indeed, not scale if it's used as
a Common Internet File System.

---

From: Michael Salmon <[email-masked]>
Date: Wed, 26 Jan 2000 07:44:06 +0100

> [check if the server is still OK and knows about it's job to notify the

Instead of having a callback wouldn't it be better to have a
changedSince call. If implemented it could return false if a directory
tree or file has not changed since the specified time. True would not
necessarily mean that changes had occurred.

/Michael

---

From: Irina Slutskaia <[email-masked]>
Date: Wed, 26 Jan 2000 10:26:06 -0500

>Roland Mainz wrote:

He is asking about uplock notifications on directories.
Didn't we discussed this topic many many times?

                                         Ira.