Disk indexers should be built into the FS, should run in the background, only ever wake up when the CPU is idle and get the hell out of the way when another process asks for CPU cycles. The user should never know that they're there, until they want to search for something.
So far, I've never yet seen one work that way on Linux. That might be the programmers' intention, but the reality is far different. Until someone can make one work properly, they're just an exercise in frustration for the user who wants to simply get the job done.
It's not just cpu. By reading files all over the disk that you're not actually interested in at the time, and writing the index which you're also not otherwise interested in at the time, they blow away the disk cache, which slows everything down regardless how low the cpu priority of the analyzer/indexer part. There are always _some_ free cpu cycles for the indexer to run in, and as long as it's allowed to run at all, it will bog down the disk i/o both by simply using it, and by flushing the cache. (same as running a backup) There is a kernel interface for telling the kernel not to cache a given transaction exactly for this kind of reason, but I don't know if any indexer, or anything else, actually uses it. The rsync developers say the interface is somewhere between impractical to impossible to use. Even if that interface _were_ used, it probably only affects the disk buffer the kernel maintains in ram. Who knows if it has any effect on the hardware buffers on the disks and in raid cards. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org