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

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 14, 2013, 10:58 UTC
Message-ID: <CACsJy8BOW-B0_gaNyL5dfdD-eKyknQEvEvf2nNy7xDWr=G02bQ@mail.gmail.com>
In-Reply-To: <7vtxof146d.fsf@alter.siamese.dyndns.org>

On Thu, Mar 14, 2013 at 2:38 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Karsten Blees <karsten.blees@gmail.com> writes:
>
>> 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."

Hey I did not know that. Webkit has about 6k leaf dirs and 182k files. Watching the top N biggest directories would cover M% of cached files:

   N     M%
  10   8.60
  20  13.28
  30  17.52
  40  20.52
  50  23.55
 200  49.70
 676  75.00
 863  80.00
1486  90.00

So it's trade-off. We can cut some syscall cost off but we probably need to pay some for inotify. And we definitely can't watch full worktree. I don't know how costly it may be for watching many directories. If it's not so costly, watching 256 or 512 dirs might be enough.

What about Windows? Does the equivalent mechanism have similar limits?

> 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.

I'm still curious how it works out. Maybe it's not up to the original expectation, but hopefully it will speed things up a bit.

-- 
Duy