All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Jon Smirl <jonsmirl@gmail.com>,
	Chuck Lever <chuck.lever@oracle.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: Beagle and logging inotify events
Date: Wed, 14 Nov 2007 14:09:19 -0500	[thread overview]
Message-ID: <20071114190919.GJ14254@fieldses.org> (raw)
In-Reply-To: <p73zlxg6e0n.fsf@bingen.suse.de>

On Wed, Nov 14, 2007 at 04:30:16PM +0100, Andi Kleen wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
> 
> > On 11/14/07, Chuck Lever <chuck.lever@oracle.com> wrote:
> >> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> >> > Is it feasible to do something like this in the linux file system
> >> > architecture?
> >> >
> >> > Beagle beats on my disk for an hour when I reboot. Of course I don't
> >> > like that and I shut Beagle off.
> >>
> >> Leopard, by the way, does exactly this: it has a daemon that starts
> >> at boot time and taps FSEvents then journals file system changes to a
> >> well-known file on local disk.
> >
> > Logging file systems have all of the needed info.
> 
> Actually most journaling file systems in Linux use block logging and
> it would be probably hard to get specific file names out of a random
> collection of logged blocks. And even if you could they would
> hit a lot of false positives since everything is rounded up
> to block level.
> 
> With intent logging like in XFS/JFS it would be easier, but even
> then costly :- e.g. they might log changes to the inode but
> there is no back pointer to the file name short of searching the
> whole directory tree.

So it seems the best approach given the current api's would be just to
cache all the stat data, and stat every file on reboot.

I don't understand why beagle is reading the entire filesystem data.  I
understand why even just doing the stat's could be prohibitive, though.

--b.

  reply	other threads:[~2007-11-14 19:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14  0:04 Beagle and logging inotify events Jon Smirl
2007-11-14 13:29 ` Chuck Lever
2007-11-14 13:44   ` Jon Smirl
2007-11-14 14:41     ` Chuck Lever
2007-11-14 15:01       ` Jon Smirl
2007-11-14 16:32         ` Chuck Lever
2007-11-14 17:46           ` Jon Smirl
2007-11-14 19:32           ` Andreas Dilger
2007-11-14 19:38             ` J. Bruce Fields
2007-11-15 19:59               ` Jan Kara
2007-11-15 20:14                 ` J. Bruce Fields
2007-11-15 20:14                 ` Jon Smirl
2007-11-14 15:30     ` Andi Kleen
2007-11-14 19:09       ` J. Bruce Fields [this message]
2007-11-14 19:22         ` Jon Smirl
2007-11-14 19:30           ` J. Bruce Fields

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=20071114190919.GJ14254@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=andi@firstfloor.org \
    --cc=chuck.lever@oracle.com \
    --cc=jonsmirl@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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.