[snip]
We have a good discussion going. To summarize...
File event types
FILE_ACCESS File was accessed
FILE_MODIFIED File was modified.
FILE_CREATE File/directory was created.
FILE_DELETE File/directory was deleted.
FILE_ATTRIB File/directory attribute changed
FILE_OPEN File was opened.
FILE_CLOSE_WRITE File that was modified got closed.
FILE_CLOSE_NOWRITE File was closed without modification.
FILE_RENAME_FROM File was renamed from this name.
FILE_RENAME_TO File was renamed to this name.
Exception events:
UNMOUNTED Watched filesystem got umounted.
DELETED File that was being watched got deleted.
OVERFLOW Events queue is full.
Additional directives,
NOTIFY_ONCE De-register after the first event delivery.
Proposal was to report multiple events as on event, like signals, till it
is read(no queuing). Also, the file events can be watched on a file or a
directory.
The interfaces will be based on the event ports interfaces. If there is
a commonly
used API, like the Linux's 'inotify' we could provide that using a library.
There appears to be a need for queuing events. Each event can provide
additional
details other then the event, ex file name when a file is created. We
could possible
provide this with some limit set on the queue size. This will address
issues with
events being generated at a faster rate then they can be read, call it
queuing issue.
Once the number of events queued exceed the limit, an OVERFLOW event is
sent to indicate
that. The subsequent events will be dropped by the system. Once the
application
receives an OVERFLOW event it can perform necessary action to find out
what has changed.
For use cases like 'Spotlight & Beagle', we need provision to watch for
file events
occurring on an entire system i.e all the mounted file systems. This can
be a scalability
issue and it also raises security concerns. These issues could be
addressed to some
extent if watching file events on an entire filesystem can be restricted
to the
'root' user. The queuing issues mentioned above will apply. Also the
event types
that can be supported when watching an entire filesystem can be a subset
of the
event types mentioned above, Ex FILE_CREATE, FILE_MODIFIED, FILE_DELETE
We can allow non root user applications to watch for file events on an
individual
file or directory.
The Spotlight like service for indexing file metadata and enabling
searches, will
have to run as root and do the necessary security checks before it can
share the
search results to non root users. This type of application will have to
have backup
procedure to collect changes that occur on the filesystem, in the case
of an OVERFLOW
event, as file events can be dropped by the kernel.
The file events from a remote node on a distributed filesystem will be
delivered as
long as the distributed filesystem has support to do so. Ex. NFSv4.1
implemention will
provide support for some types of file events. The CIFS filesystem
already has support
for this. There may not be a standard around the remote node event
notification. This
needs further thought.
The remote Spotlight implementation seems to address remote node file
change events issue
at the application level. This service will directly interact with the
remote node
Spotlight service to do the search. Not sure how are they planning on
supporting this in
an heterogeneous environment.
Behavior :
The implementation will be added as a new event source to event ports
interface.
The events will be delivered to an event port, that need to be passed
when registering.
The event port is an 'fd' and this fd is pollable.
After registering to watch events on a file or a directory, the default
behavior will be to continue to deliver events until it is de-registered.
If the 'NOTIFY_ONCE' directive is specified, it will deliver one event and
de-register automatically. This file has to be registered again to receive
file events.
The event types, being watched, can be changed by re-registering the file.
The new events are passed while re-registering.
After a file has been unlinked(removed), it will continue to watch
for events as long as this file has open references. It will deliver a
'DELETED' event when the last open references to this unlinked file goes
away.
If the filesystem on which the files are being watched is unmounted it will
de-register the watch and send an 'UNMOUNTED' event indicating that the
filesystem
has been unmounted.
These points are mainly concerning the requirements which will help
shape the API.
Thanks,
-Prakash.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
