git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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