Strange "beagle" interaction..

> 
> Ok, I've made a bugzilla entry for this for the Fedora people, but I 
> thought I'd mention something I noticed yesterday but only tracked down 
> today: it seems like the beagle file indexing code is able to screw up git 
> in subtle ways.
> 
> I do not know exactly what happens, but the symptoms are random (and 
> quite hard-to-trigger) dirty index contents where git believes that some 
> set of files are not clean in the index.
> 
> I *suspect* that beagle is playing games with the file access times, 
> causing the ctime on disk to not match the ce_ctime in the index file. But 
> that's just a guess.
> 
> I'm posting here in case somebody on the list knows what beagle does, or 
> somebody has been bitten by strange behaviour and realizes that he has 
> beagle running and prefers to fix the problem by just disabling beagle 
> (which will also be a great boon for performance - beagle seems to be very 
> good at flushing your file caches, but I guess that's not a bug, but a 
> "feature").

> 
> The easiest way I have found so far to trigger this is to run
> 
> 	while ./t7003-filter-branch.sh -i; do echo ok; done
> 
> in the git t/ directory, while at the same time telling beagle to index 
> just that git/t/ directory. That seems to trigger a failure on subtest 17 
> fairly reliably (not the first time through the loop, but *eventually* - 
> it takes a few minutes). I think it's because "git filter-branch" requires 
> the index to be clean.
> 
> (But I've also seen it fail on subtest 4).
> 
> I opened bugzilla
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=380791
> 
> for this, since I consider it a beagle bug (indexing shouldn't change 
> directory state, and if beagle wants to avoid changing access times, it 
> should use O_NOATIME). But I don't actually know exactly what it is that 
> causes problems, so if somebody is interested and tries to figure this 
> out, that would probably be good.
> 
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
> > 
> > Ok, I've made a bugzilla entry for this for the Fedora people, but I 
> > thought I'd mention something I noticed yesterday but only tracked down 
> > today: it seems like the beagle file indexing code is able to screw up git 
> > in subtle ways.
> > 
> > I do not know exactly what happens, but the symptoms are random (and 
> > quite hard-to-trigger) dirty index contents where git believes that some 
> > set of files are not clean in the index.
> > 
> > I *suspect* that beagle is playing games with the file access times, 
> > causing the ctime on disk to not match the ce_ctime in the index file. But 
> > that's just a guess.
> > 
> > I'm posting here in case somebody on the list knows what beagle does, or 
> > somebody has been bitten by strange behaviour and realizes that he has 
> > beagle running and prefers to fix the problem by just disabling beagle 
> > (which will also be a great boon for performance - beagle seems to be very 
> > good at flushing your file caches, but I guess that's not a bug, but a 
> > "feature").
> 
> Last I ran across this, I believe I found it was adding extended
> attributes to the file.  I think it's something like
> 
> 	getfattr -d
> 
> to show all the extended attributes set on the file.  Does that show
> anything?

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

>
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

> On 11/13/07, Linus Torvalds <torvalds@linux-foundation.org> 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.

> On Tue, Nov 13, 2007 at 04:44:33PM -0500, Jon Smirl wrote:
> > On 11/13/07, Linus Torvalds <torvalds@linux-foundation.org> 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.
>
> Wouldn't a simple change-attribute get you most of the way there?  All
> you need is a number that's guaranteed to increase any time a file is
> updated.

>
> Lacking that, git's current approach (snapshot all the stat data, then
> look closer at any files that appear to have been touched within a
> second of the stat) seems pretty sensible.
>
> --b.
>
> > 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.
>

> 
> Ok, I've made a bugzilla entry for this for the Fedora people, but I 
> thought I'd mention something I noticed yesterday but only tracked down 
> today: it seems like the beagle file indexing code is able to screw up git 
> in subtle ways.
> 
> I do not know exactly what happens, but the symptoms are random (and 
> quite hard-to-trigger) dirty index contents where git believes that some 
> set of files are not clean in the index.
> 
> I *suspect* that beagle is playing games with the file access times, 
> causing the ctime on disk to not match the ce_ctime in the index file. But 
> that's just a guess.