Re: Strange "beagle" interaction..
- From
- J. Bruce Fields <bfields@fieldses.org>
- Date
- Nov 13, 2007, 21:03 UTC
- Message-ID
- <20071113210354.GD22590@fieldses.org>
- In-Reply-To
- <alpine.LFD.0.9999.0711131241050.2786@woody.linux-foundation.org>
On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
Show 20 quoted lines
> > 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?
Yeah, I just turned off beagle. It looked to me like it was doing something wrongheaded.
--b.
Show 28 quoted lines
> > 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