public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <ms@teamix.de>
To: linux-kernel@vger.kernel.org
Cc: Marcin Krol <mrkafk@gmail.com>
Subject: Re: inotify limits - thousands (tens of thousands?) of watches
Date: Wed, 20 May 2009 13:22:05 +0200	[thread overview]
Message-ID: <200905201322.15075.ms@teamix.de> (raw)
In-Reply-To: <4A13CCE1.5000106@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-05-20 11:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-20  9:26 inotify limits - thousands (tens of thousands?) of watches Marcin Krol
2009-05-20 10:04 ` Matthias Kaehlcke
2009-05-20 10:12 ` Tvrtko Ursulin
2009-05-20 11:22 ` Martin Steigerwald [this message]
2009-05-20 12:16   ` Marcin Krol
2009-05-20 12:48     ` Martin Steigerwald
2009-05-20 12:58     ` Martin Steigerwald
2009-05-20 13:58 ` hooanon05

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905201322.15075.ms@teamix.de \
    --to=ms@teamix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrkafk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox