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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html