Re: fsverify.py unable to fix invalid svndiff header

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stefan Sperling wrote on Wed, May 18, 2011 at 12:12:48 +0200:
> On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> > What came out of this thread?  Is this one of the known corruption kinds?
> 
> It doesn't seem to be known.
> It could be a flipped bits on the hard drive for all we know.
> 
> > Is this is a case of a data block being written partially in one place
> > and fully in another, or a case of a corrupt or truncated data block?
> 
> Steinar shared the bad revision file privately.
> Philip Martin and myself spent a few hours at the Apache Retreat looking
> at the file but we got nowhere.
> 
> There doesn't seem to be a duplicated block. The revision file itself seems
> to be fine, expect that one of the lengths of the bad rev doesn't seem to

Huh?  Are you referring to the two 'length' attributes in the text: and
data: attributes of a node-revision?  In what way is it wrong?

> make sense. The bad representation we extracted from the file fails to
> decompress with zlib (which is what fsfsverify reported).
> 
> We could get the revision to verify fine by referring the node revision
> to a different representation but that is cheating and might break
> subseuent revs.
> 
> Steinar, I'm sorry we can't help quickly here. At the moment I have no time
> to look at this further. I hope you have a good backup you can restore from.

Re: fsverify.py unable to fix invalid svndiff header

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stefan Sperling wrote on Wed, May 18, 2011 at 12:29:41 +0200:
> On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > > There doesn't seem to be a duplicated block. The revision file itself seems
> > > to be fine, expect that one of the lengths of the bad rev doesn't seem to
> > 
> > Huh?  Are you referring to the two 'length' attributes in the text: and
> > data: attributes of a node-revision?  In what way is it wrong?
> 
> I don't remember exactly.
> I'll need a bit of time to dig into the file again before I can give a
> precise answer.

Okay.

Julian and I's discussion today raised improper memory accesses as one
potential cause --- and it could easily account for bogus rep-size (and
rep-expanded-size) issues as well.

[There was also a suggestion to get whoever can reproduce corruptions to
run mod_dav_svn under valgrind :-).]

Re: fsverify.py unable to fix invalid svndiff header

[Stefan Sperling <st...@elego.de>]

On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > There doesn't seem to be a duplicated block. The revision file itself seems
> > to be fine, expect that one of the lengths of the bad rev doesn't seem to
> 
> Huh?  Are you referring to the two 'length' attributes in the text: and
> data: attributes of a node-revision?  In what way is it wrong?

I don't remember exactly.
I'll need a bit of time to dig into the file again before I can give a
precise answer.

Re: fsverify.py unable to fix invalid svndiff header

[Stefan Sperling <st...@elego.de>]

On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > There doesn't seem to be a duplicated block. The revision file itself seems
> > to be fine, expect that one of the lengths of the bad rev doesn't seem to
> 
> Huh?  Are you referring to the two 'length' attributes in the text: and
> data: attributes of a node-revision?  In what way is it wrong?

I don't remember exactly.
I'll need a bit of time to dig into the file again before I can give a
precise answer.