[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Adding improved file search to KDE
From:       Jonathan Gardner <jgardner () jonathangardner ! net>
Date:       2004-06-15 17:57:51
Message-ID: 200406151057.51414.jgardner () jonathangardner ! net
[Download RAW message or body]

On Tuesday 15 June 2004 03:34 am, Laur Ivan wrote:
> Just looking for this stuff just yesterday.. Several file notification
> mechanisms exist: FAM (from sgi) and dnotify for example. (Here are more
> details:
> http://www.devchannel.org/devtoolschannel/04/05/13/2146252.shtml). I'm
> pretty sure one of the mechanisms (if not all) can be altered to "send"
> the name of the modified file...
>

I understand dnotify is terribly slow (some say 10x as slow). Also, dnotify 
sends a signal to the process. I would rather it had a filehandle that you 
can query. Plus, dnotify monitors only directories. I want to monitor the 
entire filesystem.

One idea that seemed good was being able to see what files are currently in 
the memory cache. If we were notified whenever a file in the cache was 
opened or stored, we could bypass the actual reading of the disk and just 
read the contents of the file from memory and index from that.

This is all speaking in the future tense, of course. I don't see any of this 
happening anytime soon. it doesn't need to be, as the alternative isn't 
completely terrible.

> > (2) We browse the filesystem, keeping resource usage to a minimum,
> > looking for modified files.
>
> mmmm... polling :)
>

This is the alternative. "locate" can index the entire filesystem in a 
matter of minutes. However, it is intrusive and consumes too much 
resources. The system is slow and unresponsive while it does this. We can 
probably do it much slower and it would still be reasonable. If the system 
is idle, we can ramp up our disk and CPU usage. If the system is busy, we 
can hold off. I think reniceing our process to a very low nice level and 
then sleeping often will give us what we need. Plus, if we keep the number 
of concurrent open filehandles to a minimum, we should be okay.

-- 
Jonathan Gardner
jgardner@jonathangardner.net
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]