Stefan Fuhrmann wrote on Sat, Jun 04, 2016 at 08:04:42 -0000: > On 2016-06-03 09:36 (+0200), Radek Krotil <radek.kro...@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
