From: Thomas Rast <trast@inf.ethz.ch>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Karsten Blees" <karsten.blees@gmail.com>,
"Duy Nguyen" <pclouds@gmail.com>,
"Git List" <git@vger.kernel.org>,
"Torsten Bögershausen" <tboegi@web.de>,
"Robert Zeh" <robert.allan.zeh@gmail.com>,
"Jeff King" <peff@peff.net>,
"Erik Faye-Lund" <kusmabite@gmail.com>,
"Drew Northup" <n1xim.email@gmail.com>
Subject: Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
Date: Mon, 18 Mar 2013 11:07:55 +0100 [thread overview]
Message-ID: <87r4jdt404.fsf@pctrast.inf.ethz.ch> (raw)
In-Reply-To: <CALkWK0=0+HYn=bSrGC5sMQOE-53As0h9dG3N9wvUB2=NW3=98A@mail.gmail.com> (Ramkumar Ramachandra's message of "Mon, 18 Mar 2013 13:54:03 +0530")
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> 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
next prev parent reply other threads:[~2013-03-18 10:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 20:17 [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline Ramkumar Ramachandra
2013-03-11 17:05 ` Heiko Voigt
2013-03-12 9:43 ` Ramkumar Ramachandra
2013-03-12 9:50 ` Erik Faye-Lund
2013-03-12 9:55 ` Jeff King
2013-03-12 23:21 ` Karsten Blees
2013-03-13 1:03 ` Duy Nguyen
2013-03-13 17:50 ` Karsten Blees
2013-03-13 19:38 ` Junio C Hamano
2013-03-14 10:58 ` Duy Nguyen
2013-03-15 16:27 ` Pete Wyckoff
2013-03-16 14:21 ` Thomas Rast
2013-03-18 8:24 ` Ramkumar Ramachandra
2013-03-18 10:07 ` Thomas Rast [this message]
2013-03-25 10:44 ` Ramkumar Ramachandra
2013-03-25 10:59 ` Duy Nguyen
2013-03-25 11:13 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4jdt404.fsf@pctrast.inf.ethz.ch \
--to=trast@inf.ethz.ch \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karsten.blees@gmail.com \
--cc=kusmabite@gmail.com \
--cc=n1xim.email@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=robert.allan.zeh@gmail.com \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).