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