On Wed, Jul 31, 2013 at 3:57 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Jan (CC'd) reported an odd problem on IRC today: he would get
>
> Corrupt representation '537009 564 9641 0
> 61d9000a8ccca3379173bbbbe0bb15bc' [500, #160004]
> Malformed representation header at
> /swdev/ssd/CONVERSION/SVN/test/db/revs/537/537009:593
>
> *sometimes* when he ran 'update --parents' that pulled in
> a not-yet-in-the-wc file.
Even a corrupted FS may not always cause access failures
(depending on cache status, delta chains etc.). The default
strategy would be to run svnadmin verify.
> The errors went away after he restarted
> httpd. The error log had an EPERM on rev-prop-atomics.mutex which may
> or may not be related.
>
Well, the Apache / SVN user should get write access to the
repo folder. Otherwise, revprop caching won't work. But that
issue is not related to the corruption.
> Now, that error is actually very odd:
>
> - "61d9000a8ccca3379173bbbbe0bb15bc" doesn't occur anywhere in the
> filesystem
> (rep-cache.db and db/revs/**/*)
>
My first reaction as "cross-talk". Philip's explanation is probably
the most likely one.
> - byte range [564, 564+9641] does not contain a start or end of a
> representation;
> there is a representation
> text: 537009 0 11118 3095593 e7f245ae8b4f219170fd5376e0fa4d02
> c217337f689a3b2b7b87faf6267371af031d70a0 537008-bicw/_5
> and I checked, it starts and ends in the right places (it is a DELTA
> rep having a 20-byte header).
> - Note that "593" is a byte offset, not a line number.
> - The '0' either means "expanded size unknown", or --- if it means "the
> expanded size is zero" --- then the md5 is wrong.
>
0 means PLAIN representation in this case.
> - The error message above is generated by representation_string(). The
> filesystem is f6, so representation_string() should include the sha1
> and uniquifier in its output; but it doesn't.
>
Hashes (directories, properties) don't store a SHA1 for their
representation.
Since there is no fsfs.conf file, this repo does not use directory
deltification
which makes it likely that SVN is trying to access a directory
representation
(PLAIN, no SHA1).
>
> Environment:
>
> - svn 1.8.1, wandisco package
> - httpd-2.2.15-28.el6
> - CentOS 6 64bit
> - client and server run on the same machine
> - fsfs.conf is empty
>
-- Stefan^2.
Received on 2013-07-31 17:01:44 CEST