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

List:       kde-devel
Subject:    Re: Adding improved file search to KDE
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2004-06-15 18:12:50
Message-ID: 1087323169.8767.91.camel () localhost ! localdomain
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


El mar, 15-06-2004 a las 12:57, Jonathan Gardner escribió:
> 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).

it actually sends signals SO fast, receiving processes can't keep up
with them and hit 100% CPU usage trying to refresh the view.

>  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.

Good point.  But no filehandles since keeping open fds will lead to
cd-rom tray blocking and other nasty stuff.  check nonotify in google to
see if that works, and push for its incorporation on the linux kernel.

> 
> 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.

the cache is an os protected area, and apps are supposed to simply not
be aware of it.  you also don't need to peek at the cache to read a file
fast, if the file was recently opened it should already be there and
requesting the file from disk would actually result in requesting the
file from cache without your app needing to know the specifics.

> 
> 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.

I agree, if you're using a 2.4 kernel.  If locate slows your system too
much, anyway, you can make it run with a higher niceness level.

>  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.
-- 
	Manuel Amador
	Jefe de I+D                         +593 (9) 847-7372
	Amauta                     http://www.amautacorp.com/
	GNU Privacy Guard key ID: 0xC1033CAD at keyserver.net

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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