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.
I don't see why this couldn't be done on Linux as well.
---------- Forwarded message ----------
From: Jon Smirl <jonsmirl@xxxxxxxxx>
Date: Nov 13, 2007 4:44 PM
Subject: Re: Strange "beagle" interaction..
To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, Junio C Hamano
<gitster@xxxxxxxxx>, Git Mailing List <git@xxxxxxxxxxxxxxx>, Johannes
Schindelin <Johannes.Schindelin@xxxxxx>
On 11/13/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 13 Nov 2007, J. Bruce Fields wrote:
Last I ran across this, I believe I found it was adding extended
attributes to the file.
Yeah, I just straced it and found the same thing. It's saving
fingerprints
and mtimes to files in the extended attributes.
Things like Beagle need a guaranteed log of global inotify events.
That would let them efficiently find changes made since the last time
they updated their index.
Right now every time Beagle starts it hasn't got a clue what has
changed in the file system since it was last run. This forces Beagle
to rescan the entire filesystem every time it is started. The xattrs
are used as cache to reduce this load somewhat.
A better solution would be for the kernel to log inotify events to
disk in a manner that survives reboots. When Beagle starts it would
locate its last checkpoint and then process the logged inotify events
from that time forward. This inotify logging needs to be bullet proof
or it will mess up your Beagle index.
Logged files systems already contain the logged inotify data (in their
own internal form). There's just no universal API for retrieving it in
a file system independent manner.
Yeah, I just turned off beagle. It looked to me like it was doing
something wrongheaded.
Gaah. The problem is, setting xattrs does actually change ctime.
Which
means that if we want to make git play nice with beagle, I guess
we have
to just remove the comparison of ctime.
Oh, well. Git doesn't *require* it, but I like the notion of
checking the
inode really really carefully. But it looks like it may not be an
option,
because of file indexers hiding stuff behind our backs.
Or we could just tell people not to run beagle on their git trees,
but I
suspect some people will actually *want* to. Even if it flushes
their disk
caches.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jon Smirl
jonsmirl@xxxxxxxxx
--
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-
fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
