Re: Things that Longhorn seems to be doing right

[Ingo Oeser <ioe-lkml@rameria.de>]

On Thursday 30 October 2003 04:12, Joseph Pingenot wrote:
> being in userspace.  The cost is the context switching performance hit and
> the fact that each process that wants to index its stuff must tell the
> filesystem and the indexing service its data (effectively, two writes and a
> completely separate API).  [I'm likely preaching to the choir here, but
> it's good to outline it]

To tell the data, you just have to create a mapping of a file and
pass that somehow. So you get it fresh from the pagecache.

Since the indexer will just read it, this mapping will be even shared,
which means it will not affect disk performance of the other
applications using this file.

Also notice, that no global index is needed, but per user ones, which
must be mergable with a global one.

Rationale: User A should not know the file contents of user B.

And currently indexing is sloooow. I tried glimpse and htdig and they
run several hours just for indexing the KDE and QT documentation.

This let me come to the conclusion that a small keyword generator
(strings?) run after fsync, which stores autogenerated keywords in the
nearest index (per file, per directory, per user, global) might be better.

Another interesting idea might be using existing indexes by letting
applications define a search handler. This might prove useful for
databases and will allow for unified search. But that might prove to be
quite hard.

Regards

Ingo Oeser