The decompression errors only seem to happen when we're sending binary
data. For a couple of years our marketing team were storing all of their
files in subversion and this seems to be the vast majority of the revisions
I'm having to fix with fsfsverify.py. So it could possibly be that they
were using a TortoiseSVN version that was built with a buggy library.
That said the problematic revision that this thread is about was one
created by our engineering team and all of our work is done from linux
machines so would have been a different client (cli subversion client). So
it sounds more likely that it's something server side. We do still get the
issue periodically, so there's a chance it could be related to the NAS that
the repo is stored on. We did recently move to a new NAS as the old one was
getting a bit slow but we hadn't seen any corruption issues with the old
NAS, just slowness. I'm not sure if we've had any svndiff issues since
we've moved to the new NAS, I'll find out when I've finally got to the
point where it's syncing commits from the last month.
Also the issue would happen straight away. i.e. if someone tried to do an
svn up immediately after a commit had been made they would get the svndiff
error. So it seems like it was an error that occurred when the svnserve
process received it or wrote it to the file system. So it's not hard disk
corruption after the fact (but again doesn't rule out a NAS issue).
Sorry for not being able to provide more specific details. If I see it
happening again once we've moved over to a modern OS and Subversion server
I'll email back again.
Mike
On Fri, 30 Aug 2019 at 14:22, Branko Čibej <brane_at_apache.org> wrote:
> On 30.08.2019 15:14, Michael Ditum wrote:
> > Hi Brane,
> >
> > Thanks for the reply. Interestingly Daniel's reply had given me the
> > idea to try pretty much what you suggested and I gave it a go this
> > morning and it seems to be working.
> >
> > Stopping svnsync in the right place wasn't hard as i dies as soon as
> > it tried to get the binary diff but before it's made any changes.
> >
> > The one bit I didn't do was update the svnsync metadata. When I
> > resumed the sync it just automatically carried on with the revision
> > after the one I had just committed. Hopefully that won't cause any
> > problems, it seems to be working ok as I'm a lot further syncing than
> > I've ever managed before (crazy how many times we've had svndiff
> > errors, luckily fsfsverify has fixed all of the others so far).
> >
> > Thanks for everyone's help!
>
> Great that it works. :)
>
> I'm curious though ... have you any idea what caused the decompression
> errors? The message you posted came from zlib -- not Subversion's code
> -- and that has been very, very stable literally for decades.
>
> Is it possible that you just had the bad luck to have a broken version
> of zlib, way back in the dawn of time? If it had been a problem with the
> storage, I'm pretty sure you'd have noticed other issues, too.
>
> -- Brane
>
>
Received on 2019-08-30 19:17:12 CEST