Stefan Fuhrmann wrote on Sat, Jun 04, 2016 at 08:04:42 -0000:
> On 2016-06-03 09:36 (+0200), Radek Krotil <radek.krotil_at_polarion.com> wrote:
> > Hello.
> >
> > Today, I encountered a problem when trying to pack a repository after
> > migrating it to the FSFS 7 format by performing full dump / load sequence.
>
> I assume you ran 'svnadmin load' onto a repository
> that was not accessible to the server at that time,
> so no remote user could accicentally write to it?
Why would that matter? What could happen if somebody makes a commit or
a propedit in parallel to an 'svnadmin load'? A concurrent commit will
cause mergeinfo in later revisions to have to have off-by-one errors,
but shouldn't cause FS corruption.
> > Shortly, I get the following error
> > âPacking revisions in shard 5...svnadmin: E160056: Offset 391658998 too
> > large in revision 5102â
>
> This is basically an "invalid access" error message.
> Typical causes include repository corruption and
> admins tinkering with the repository without informing
> the server process. A maybe similar issue:
>
> https://issues.apache.org/jira/browse/SVN-4588
>
> In your case, however, the corruption is probably in
> the repository itself. Please run 'svnadmin verify' on it.
>
> > I was not able to understand from the documentation, what settings in
> > fsfs.conf should be modified to workaround this problem. Neither search in
> > the Internet brought any light into this. Is it even possible?
>
> This is most definitely not a configuration issue like
> "your data is too large". Maybe, we should prefix the
> error message with "invalid access" to prevent
> confusion.
How about being even more specific:
svnadmin: E1600NN: failed to locate representation of %s at revision %ld, offset %lld
where %s identifies the origin of the offset value or the object that
was expected to be located at that offset.
?
Cheers,
Daniel
Received on 2016-06-04 18:57:24 CEST