Regular repository corruption -- help needed.

[Matt Mackall]

On Thu, 2012-12-20 at 21:37 +0100, Alexander Krauss wrote:
> On 12/20/2012 01:49 AM, Bryan O'Sullivan wrote:
> > During a push, Mercurial uses a special redirection mechanism to add
> > entries to the changelog file. That mechanism is very simple: it writes
> > data to a temporary file, then reads the contents of that file and
> > writes them to the end of the real changelog after all of the
> > changegroup has streamed through.
> >
> > The forensics that I see are 100% consistent with a situation where your
> > NFS client happily says "here's your file full of zeroes" when you read
> > back a file (not full of zeroes) that you wrote earlier. You are not
> > guaranteed write-to-read consistency even on a single node (whatever the
> > specs may say).
> 
> I see. Is this analysis consistent with the fact that already-existing 
> changesets get corrupted by the push?

Probably not. Exceptions include doing strip or rebase or other
modifications on the server, or revlogs growing past the 128k
de-interleaving threshold at the time of the corruption.

For NFS to write to random earlier points in a file when opened in
append mode would be a pretty good trick without help from a hardware
glitch or other OS bug. Such damage also points to lower-level problems
like I suggested earlier. It's much more likely to be a server-side
problem, but you can't completely rule out clients.

> Yes. Here, local just meant that no ssh was involved. Both source and 
> destination repository live on NFS.

We can be pretty confident that data from the source repo is read
correctly, even though it's on NFS.

-- 
Mathematics is the supreme nostalgia of our time.