Re: inotify limits - thousands (tens of thousands?) of watches

[Martin Steigerwald]

Am Mittwoch, 20. Mai 2009 schrieb Marcin Krol:
> Hello everyone,
>
> First, apols for using up bandwidth, but I honestly found no other place
> where I can ask about this (and get meaningful reply).
>
> I'm not a kernel programmer, but I want to develop a program that would
> watch modifications in *all* user directories on a busy server using
> inotify.
>
> This is for high-availability purposes - events would be collected and
> once every several minutes changed dirs would be rsync'ed to failover
> server or smth like that would be done.

Hmmm, I think you could just run a rsync periodically. It might even be faster 
detecting changed files. Unless you are talking really high number of 
directories and files.

> As inotify watches particular directory and not its subdirs, I would
> have to watch all directories.

Yes. Thats cumbersome.

> This means I would have to create thousands or even tens of thousands of
> inotify watches.

I wrote a ruby script using libinotify-ruby which does just that. I only syncs 
on demand tough. I.e. when someplace places a special sync file in a watched 
directory.

> So my questions are:
>
> 1. is it safe? that is, will it not lock the kernel up, or cause
> excessive memory consumption?
>
> 2. is it economic in terms of CPU time and RAM? I have no idea how to
> even measure such a thing happening in the kernel..

That script is running productively for well over a year now.

There have been some problems with it stopping doing work occasionally. It has 
to be restarted. Now there is a monitor process which restarts it 
automatically should it end. Might be a race condition or programming error 
in the script. But the customer is happy with the workaround and didn't want 
me to put any further efforts in finding the real cause.

Regarding the inotify implementation in the kernel I darkly remember that 
there were some improvements. Search inotify or fsnotify in kernel-ml.

Ciao,
-- 
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Attachment: signature.asc
Description: This is a digitally signed message part.