All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: Jamie Lokier <lk@tantalophile.demon.co.uk>, linux-kernel@vger.kernel.org
Subject: Re: FS callback routines
Date: Thu, 11 Jan 2001 15:30:14 +0100	[thread overview]
Message-ID: <3A5DC376.D9E5103F@innominate.de> (raw)
In-Reply-To: <3A5A4958.CE11C79B@goingware.com> <3A5B0D0C.719E69F@innominate.de> <20010110115632.E30055@pcep-jamie.cern.ch>

Jamie Lokier wrote:
> Daniel Phillips wrote:
> > [things that can benefit from dnotify]
> > locate (reindex only those directories that have changed, keep index
> > database current).
> 
> Not a chance.  dnotify doesn't work recursively, so you can't monitor
> just a few top level directories like "/usr/lib".  And have you ever
> tried to keep all 3000 directories on your filesystem directories open
> at the same time?  Would you want to consume that much non-swappable
> memory, and also prevent the directories from being removed from the
> filesystem?
> 
> Long ago I proposed something similar that works at the disk level, is
> recursive, and the checks can be done without keeping directories open.
> But I never wrote the code :(  That's interesting because it speeds up
> make without needing a daemon, and really can speed up
> locate/updatedb/find.

It took a little while for the following to dawn on me: it's not hard to
make the dnotify scheme work recursively and you don't have to keep 3000
directories open.  To modify a file you must have opened all the
directories in its path.  We need a new event: 

        DN_OPEN       A file in the directory was opened

You open the top level directory and register for events.  When somebody
opens a subdirectory of the top level directory, you receive
notification and register for events on the subdirectory, and so on,
down to the file that is actually modified.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-01-11 14:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-08 23:12 FS callback routines Michael D. Crawford
2001-01-09  2:37 ` Sean R. Bright
2001-01-09  3:48 ` David Weinehall
2001-01-09 13:07 ` Daniel Phillips
2001-01-10 10:56   ` Jamie Lokier
2001-01-10 18:25     ` Daniel Phillips
2001-01-11 14:30     ` Daniel Phillips [this message]
2001-01-11 15:37       ` Jamie Lokier
2001-01-11 16:11         ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-01-09  1:21 Sean R. Bright
2001-01-09 11:22 ` Philipp Matthias Hahn
2001-01-09 11:34 ` Daniel Stodden
2001-01-09 14:05 Jesse Pollard
2001-01-09 15:41 ` Daniel Phillips
2001-01-10 10:48   ` Jamie Lokier
2001-01-10 15:18 Jesse Pollard
2001-01-11 16:39 Jesse Pollard
2001-01-11 17:53 ` Daniel Phillips

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=3A5DC376.D9E5103F@innominate.de \
    --to=phillips@innominate.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lk@tantalophile.demon.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.