Re: Comments about indexing and query solving in user land

["daniel.poelzleithner" <poelzi@poelzi.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grzegorz Jaśkiewicz wrote:

|>        In our project http://sourceforge.net/projects/linuxsfs-tm/ we
did the
|>attribute indexing and query parsing in the user-space and we had hooks
|>in the VFS which communicated with the user-space deamons. As far as
|>directory listing is concerned we had a in kernel-recordset cache
|>(hashed on the query). The listing were pretty efficient.
|>
|>        But the real problem occured when a large number of files were
copied
|>in the onto our file system. All the files now need to be indexed in the
|>user space , leading to mode switch. That was pathetically slooow. The
|>entire 2.4 sources were copied in 5-6 hours. I think this problem could
|>be solved by batching requests the user space deamon.  Then u have all
|>the problems on missing out on indexing on a large set of files.
|
| I think that should give you pretty much explanation why whole VFS
| layer and filesystems are in kernel not in user space. That's where
| such sort of thing belongs to. I have no doubts.

I think such operations should be a background task. When a new file is
created, the file should be added to a index queue and the file
operation should return. These queue list will be processed by an
background daemon.
Only when meta data are accessed which is unindexed the file will be
removed from the queue and proccessed instandly, so the system call can
return.
I think such a technique would reduce the speed impact indexing brings.

regards
~ Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBPhV1y/mkIQp7AD0RAqonAJ9ww2VAPKnX7u9q1euyKZbYBK9zGQCg2fI9
mC6bQ5IiRuafCrX+O3I7oJw=
=Q8mj
-----END PGP SIGNATURE-----