I found the following which talks about the file event notification
facility in Apples OS X 10.4. The fslogger is a utility which uses this
feature. Apparently this is the same feature used by 'Spotlight' too
http://www.kernelthread.com/software/fslogger
Their file events notification mechanism is available only to root. It
also mentions that the events get queued up and once the queue is full,
the kernel will drop events. But it will send an event indicating that
the queue is full. I Linux's 'inotify' implmenentation is also similar.
It sends a 'OVERFLOW' event when the queue gets full.
Spotlight..
Is a system service for searching files in a desktop environment.
From reading the article that Eoin has provided, tt can accept complex
search queries based on file attributes. It uses extended file
attributes(called metadata)for indexing. It has APIs defined so that
applications can use to interact with this service.
It appears to use file events to monitor for any changes to files
and directories on all the filesystems on the desktop and update its
index data base. Obviously this would not be very effective on
any distributed filesystem mounted.
If it is possible for Spotlight to miss events, since the
kernel can drop it when the queue is full, it must use
some user land search mechanism as a backup. I could not
see this mentioned in the article.
So, if that is the requirement, we can have similar functionality
on Solaris too. The queue size could be specified when registering
to watch the events. There should be a hard limit defined
so that the system does not get overwhelmed by the flood
of events. An out of band OVERFLOW event can be sent once the queue
gets full. The application will have to take appropriate action if
the queue get full and it receives an OVERFLOW event.
We could restrict watching file events, on an entire filesystem/directory
tree or on all the filesystems in the system, only to root. But allow
watching an individual file or directory to all users.
If the purpose of watching file events on an entire filesystem
is for indexing like what Spotlight does, then this should
be provided as system service and have API's for applications to
interact with this service, rather then different applications trying
to duplicate it.
-Prakash.
Eoin Lawless wrote:
As far as I know, Beagle is similar to Spotlight rather than the other
way round - it tries to copy Spotlight. It was very far behind Spotlight
when I last tried it.
A good article on file system events, indexing and search in Apple's
MacosX 10.4 Tiger is at:
http://arstechnica.com/reviews/os/macosx-10.4.ars/
(sections 6 to 12).
Eoin
On Thu, 2006-05-04 at 21:32, Michael Pogue wrote:
See also Apple's Spotlight, which is similar to Linux's Beagle. I believe that
Windows-Next will also have this capability. So, yes, I think this should be a
primary use case for this new API.
Mike
John Levon wrote:
On Wed, May 03, 2006 at 07:31:08PM -0700, Prakash Sangappa wrote:
If you where to watch for events on an entire directory tree, what types
of events that would be?
Presumably there would be some way to specify, but file creation/deletion would
be the most obviously useful events.
How would this be useful?
Beagle wants it, I think:
http://beaglewiki.org/Main_Page
as well as some other GNOME things, apparently.
can be to just a watch on the directory "/etc". The FILE_CREATE event would
mean that a file or a directory was created under "/etc". Once the
application gets this event, it can go and check if the file got created.
Does this mean we don't get told /what/ got created? Is an application that
wants to know "what files are disappearing/appearing under /foo/bar/?" going to
have to readdir() the whole directory every time it gets an event?
How does it interact with unmounting the underlying filesystem?
It will hold a reference to the 'vnode' of the file/directory in the kernel,
while we have the file events monitor on it. If the file system gets
unmounted, it will de-register the monitor and send an exception event saying
the filesystem got unmounted. These exception events need to be defined.
Sounds sensible...
regards
john
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
