config option for KDirWatch method

Flavio Castelli micron at bglug.it
Tue Aug 21 14:16:02 BST 2007


On Friday 17 August 2007 16:29:29 Dirk Mueller wrote:
> > Inotify has a limit on the number of directories
> > it can watch
>
> wrong.
No it isn't, Jos is right. Let me do a short introduction on how inotify 
works.
First of all you have to create a inotify instance. Then if you want to 
monitor a file or a directory, you've to create a watch object (which is 
associated to your fresh inotify instance).
When you "add" a watch over a directory you'll be notified of all changes 
happening inside of it. But you _won't_ be notified when something happens 
inside one of its subfolders.  So, if you want to be reported of _all_ the 
changes happening in a directory, you have to add a watch to the parent 
directory and (recursively) to all its subfolders. 
Any time something happens inside one of the watched resources, the kernel 
creates an event object and puts it inside a queue owned by a specific 
inotify's instance.
In the user space, programs just pool their inotify queues and process events.

Since inotify uses kernel's memory three limitations have been introduced:
- the maximum number of inotify instances owned by an user
- the maximum number of watches owned by an user
- the maximum number of events owned by an user

You can see these limit under proc fs: 
- /proc/sys/fs/inotify/max_queued_events
- /proc/sys/fs/inotify/max_user_instances
- /proc/sys/fs/inotify/max_user_watches

Only root user can change these limits.

The most annoying limitation is the second one: the maximum number of watch 
objects per user. By default this limit is set to 8192 watches. I assure this 
isn't  enough when you try to monitor all your home directory (we have 
noticed it working with Strigi).

> wrong as well :)
I think Jos referred to inotify's scalability problems.

Cheers
	Flavio

-- 
| micron<- ICQ #118796665
| GPG Key:
|  ~ Keyserver: pgp.mit.edu
|  ~ KeyID: 6D632BED

~ "Progress is merely a realisation of utopias" ~




More information about the kde-core-devel mailing list