Mailinglist Archive: opensuse (868 mails)

["Brian K. White" <brian@xxxxxxxxx>]

> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx