Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

From: Thomas Rast <trast@inf.ethz.ch>
Date: Mar 18, 2013, 10:07 UTC
Message-ID: <87r4jdt404.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <CALkWK0=0+HYn=bSrGC5sMQOE-53As0h9dG3N9wvUB2=NW3=98A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 27 quoted lines

> Junio C Hamano wrote:
>> Yes, and you would need one inotify per directory but you do not
>> have an infinite supply of outstanding inotify watch (wasn't the
>> limit like 8k per a single uid or something?), so the daemon must be
>> prepared to say "I'll watch this, that and that directories, but the
>> consumers should check other directories themselves."
>>
>> FWIW, I share your suspicion that an effort in the direction this
>> thread suggests may end up duplicating what the caching vfs layer
>> already does, and doing so poorly.
>
> Thomas Rast wrote:
>>   $ cat /proc/sys/fs/inotify/max_user_watches
>>   65536
>>   $ cat /proc/sys/fs/inotify/max_user_instancest
>>   128
>
> From Junio's and Thomas' observations, I'm inclined to think that
> inotify is ill-suited for the problem we are trying to solve.  It is
> designed as a per-directory watch, because VFS can quickly supply the
> inodes for a directory entry.  As such, I think the ideal usecase for
> inotify is to execute something immediately when a change takes place
> in a directory: it's well-suited for solutions like Dropbox (which I
> think is poorly designed to begin with, but that's offtopic).  It
> doesn't substitute of augment VFS caching.  I suspect the VFS cache
> works by caching the inodes in a frequently used directory entry, thus
> optimizing calls like lstat() on them.

I have three objections to changing the kernel to fit us, as opposed to just using inotify:

* inotify works.  I can watch most of my $HOME with the hack I linked
  earlier[1].  Yes, it's a lot of coding around the problem that it is
  nonrecursive, but we already have a lot of code around the problem
  that we can't ask the VFS for diffs between points in time (namely,
  the whole business with an index and lstat() loops).

* inotify is here today.  Even if you got a hypothetical notifier into
  the kernel today, you'd have to wait months/years until it is
  available in distros, and years until everyone has it.

* I'll bet you a beer that the kernel folks already had the same
  discussion when they made inotify.  There has to be a reason why it's
  better than providing for recursive watches.

[1]  https://github.com/trast/watch

-- 
Thomas Rast
trast@{inf,student}.ethz.ch