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

[Ramkumar Ramachandra <artagnon@gmail.com>]

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.

The correct solution for our problem is to get VFS to recognize our
repository as a unit: the repository is not a bunch of frequently-used
directory entries, but a frequently-used unit in itself.  We need an
optimization that will work on recursively on a directory entry.
However, since the repository is a special usecase, I suspect adding
an rwatch() system call (or similar) will be necessary to register the
repository with VFS.  The design of this feature should be transparent
to userland, and their filesystem calls will be optimized magically.
We certainly don't need something as fine-grained as inotify to
perform these optimizations: if the tree hash of a registered
repository changes frequently enough, we have to optimize operations
on that directory tree (recursively).

Inputs from btrfs/ vfs hackers would be appreciated.  I'll take out
some time to look at them myself this week.