Inotify causing silent merge corruptions ?!

Matt Mackall mpm at selenic.com
Wed Dec 31 17:51:13 UTC 2008


On Wed, 2008-12-31 at 16:06 +0000, Marc Bevand wrote:
> Marc Bevand <m.bevand <at> gmail.com> writes:
> > 
> > This occured with Mercurial at revision 11660d2918af (1.1.1 + some
> > trivial changes), running on Linux kernel 2.6.27, with the inotify
> > extension, on a large repo (700MB, 100k files) residing on a local XFS
> > filesystem. I suspect an inotify bug, maybe a race condition. I cloned
> > my repo to be in the state it was at right before the merge, to
> > reperform the merge, but this time it does merge as expected. Next thing
> > I am going to try is to write a script to repeatedly attempt the merge.
> > If it is a race condition in inotify, it should eventually reproduce the
> > bug.
> 
> I wrote that script and it does reproduce the merge corruption everytime on my 
> repo! As I predicted it seems to be a race condition: if hg merge is 
> immediately succeeded by hg commit (with no pause in between), some files will 
> not be merged at all (as if inotify was still updating the dirstate or 
> something in the background). If I either insert a sleep 5 between the two 
> commands, or disable inotify altogether, everything is fine.
> 
> I am now trying to build a test case to allow anyone to reproduce the bug, but 
> the race condition seems to be dependent on the complexity of the repo (in my 
> case thousands of files were being merged). And so far my attempts to build 
> test repos with thousands of dummy files failed to reproduce the bug.

The inotify extensions has a mode:

[inotify]
debug = 1

...that calls inotify and compares it with the result of normal status.
Please give it a try.

I'm afraid inotify having troubles is not terribly surprising. I've
fixed several bugs in it for 1.1, but I suspect a few remain. 

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial mailing list