On Tue, Nov 13, 2007 at 04:03:54PM -0500, J. Bruce Fields wrote:
quoted text
> 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?

By the way, on Debian or Ubuntu, at least, that requires an "apt-get
install attr" first.

quoted text
> 
> Yeah, I just turned off beagle.  It looked to me like it was doing
> something wrongheaded.

Just looking at the attribute names and taking a wild guess, it looked
to me like beagle was computing a checksum of each file's data and
comparing it to a checksum previously stored in an xattr, and using that
to decide whether to reindex the file data.

With the result that to check whether anything's changed when it starts
up again it has to read through the entire filesystem's data.

Maybe I'm wrong--I hope so.  I'd love to know.

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