Junio C Hamano [off-list ref] writes:
Karsten Blees [off-list ref] writes:
quoted
However, AFAIK inotify doesn't work recursively, so the daemon
would at least have to track the directory structure to be able to
register / unregister inotify handlers as directories come and go.
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."
Those are tunable limits though. For example I run this silly hack
https://github.com/trast/watch
with the shell snippets to be able to quickly cd a shell to where
something recently happened. I am able to watch most of my "working
set" even under default limits, which here (opensuse tumbleweed, kernel
3.8.x, x86_64) are
$ cat /proc/sys/fs/inotify/max_user_watches
65536
$ cat /proc/sys/fs/inotify/max_user_instances
128
I'm not sure if other distros impose tighter limits by default, but as
it stands you're not very likely to hit the 65k watches limit in any
given repo. It seems more likely that you might hit the 128 instances
limit if we go with a design that uses one daemon per repo, if you run a
script that accesses many repos. For example, in an android tree I have
lying around,
$ repo list | wc -l
297
That alone might indicate it would be a good idea to have one "global"
git-agent that starts on demand, rather than a per-repo daemon.
Otherwise we'd have to find a way to discover "old" daemons and tell
them to quit when we hit max_user_instances.
--
Thomas Rast
trast@{inf,student}.ethz.ch
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.