[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Another FSFS bug somewhere?

From: John Szakmeister <john_at_szakmeister.net>
Date: Thu, 2 Sep 2010 07:09:43 -0400

On Thu, Sep 2, 2010 at 6:48 AM, Stefan Sperling <stsp_at_elego.de> wrote:
[snip]
> Just a possibly related note:
>
> I've been investigating broken FSFS revisions at a customer site,
> which fsfsverify.py was able to fix. fsfsverify.py reported
> "InvalidCompressedStream" and/or "InvalidWindow" errors.
> I haven't found the time yet to fully dig into the problem to figure out
> what really happened. I do have the corrupt and fixed revision files for
> analysis and will try to pin-point the problem based on them.

I think that's the repeated block issue. When the problem occurs with
a compressed stream, it gets a little more interesting... but it's
usually recoverable.

> Given what I know about the scenario at the customer site, there seems to
> be a correlation between revprop edits and corruption of revisions,
> even of revisions unrelated to the revisions which received the revprop
> edits (though I'm not sure yet if that's really the case). Julian Foad
> says he's seen similar issues also possibly related to revprop edits,
> but it's unclear whether we're seeing the same problem.

I've seen several cases where propedits have gone bad and you end up
with an empty file. I haven't seen much in the way of corruption on
that front though (no weird looking bytes, or a malformed file...
other than it being empty). Perhaps there is a correlation between
editing properties and causing a subsequent problem in a revision. I
haven't personally seen that trend though. OTOH, a great deal of
people come to me for help, but are unwilling to share many details.
:-(

> I do think there could be a long-standing bug we need to fix.
> In the case I saw, the server was on 1.4, but in Julian's case the
> server was on 1.6. Maybe you're seeing the same or a similar problem,
> with a presumably "very recent" server?

This one was different than most that I had seen. Almost everything
in the text: line was right except for the revision number. It
referenced 38904, and it should have referenced 38910. I know we've
had some caching bugs in the past, and I'm curious if this is another
one.

> John, if you had time for a quick IRC session where you could explain
> the ideas behind fsfsverify.py to me at a high level and answer questions,
> I'd be grateful. And I'd very much like to see its functionality inside
> of svnadmin verify/recover, partly because I believe that reimplementing
> it there would give me great insight into the problem :)

I can do that. My schedule is a bit wonky though. Early morning
Eastern Standard Time works best for me (I'm usually up 4:30ish). Let
me know what works for you.

TTYL!

-John
Received on 2010-09-02 13:10:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.