On Wed, 2006-05-10 at 23:28, prakash sangappa wrote: Spotlight.
The distributed filesystem issue is somewhat addressed by remote spotlight: http://weblog.infoworld.com/enterprisemac/archives/2006/04/remote_desktop.html "Remote Spotlight is a hugely useful feature. It launches Spotlight searches on multiple remote clients simultaneously and returns the results fast, grouped by client, to the ARD console. In other words, it's a LAN-wide Spotlight search with the same criteria you use with Tiger Spotlight, and uses each machine's local index and application-specific importers. Like Tiger Spotlight, you can narrow the results with qualifiers after the results are displayed." A full index of a filesystem can be started manually - in fact this happens the first time OS X 10.4 is booted up. I was very impressed when I first used Spotlight. Start a spotlight search for 'foobar'. In Terminal do "vi file.txt" type in 'foobar', save and file.txt instantly appears in the spotlight search window. However, if you call the file just 'file' it is missed! - a side effect of the way the indexing/importing works. Nevertheless it's far and away the best _desktop_ search system I've yet used. > 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
