Re: [TCLCORE] TIP #384: Add File Alteration Monitoring to the Tcl Core

[Cyan O. <cya...@gm...>]

On Wed, Dec 8, 2010 at 7:28 PM, Larry McVoy <lm...@bi...> wrote:

> On Wed, Dec 08, 2010 at 05:49:12PM +0100, Reinhard Max wrote:
> > Hi,
> >
> > On Wed, 8 Dec 2010 at 17:30, Larry McVoy wrote:
> >
> >> On Wed, Dec 08, 2010 at 05:19:58PM +0100, Reinhard Max wrote:
> >
> >>> I don't like it, because it forces platforms that do have more
> >>> efficient notifier mechanisms to work as inefficient as those that
> >>> don't have it.
> >>
> >> Greatest common denominator.
>
> The reason that people do dir only is performance and scaling.  If the
> user process says "I want to know about any change in all file systems"
> that's a lot of potential changes.  On a Linux local file system I can
> do over 100,000 4K file creates per second and over 175,000 deletes per
> second.  Let's take 100K as a number.  That's 10 microseconds per event.
> Chew on that.


There are obviously going to be situations that aren't possible to manage,
but that doesn't invalidate that there are valid use cases that are
perfectly feasible.  The main use I find for inotify is fixing the broken
integration systems, like: MFP uploads scanned documents via ftp, java app
polls directory and reads documents into database.  A tiny Tcl script that
watches the incoming dir for IN_CLOSE_WRITE and does a move to another dir
on the same filesystem that the java app polls - no more race.  We've load
tested that setup to far beyond what the entire country's MFPs can generate
for days without breaking a sweat, and the system has been solid in
production for a few years.

Having the facility in the core would have meant I could have catered for
the existing AIX/PPC blades rather than moving them to Linux/x86 (not a bad
thing, but less work is good).  That is if AIX even has the low level
facility for monitoring file close.

Cyan