Re: "Offset too large" error when packing repository in FSFS 7 format
From: Radek Krotil <radek.krotil_at_polarion.com>
Date: Mon, 22 Aug 2016 11:38:00 +0200
Thanks Stefan and Daniel for your effort in analyzing this. Unfortunately,
Recently I hit this problem on another production repository from one of my
2) Rename it to repo-x, where x is the format of the repository
4) Create new repository named repo-1.9
5) Load the dump to the new repository
6) Pack the repo-1.9 repository
7) Configure Polarion ALM to use the repository
8) Start Polarion – only at this point is the repository first used by
There is a svnserve process serving all repositories under
On this particular repository, I ran the dump/load cycle twice and in both
[root_at_babybear svn]# svnadmin pack repo-1.9/
Packing revisions in shard 203...svnadmin: E160056: Offset 232966338 too
[root_at_babybear 203]# grep -oba L2P-INDEX 203908
I tried to restart Apache, svnserve, even the whole box. The problem still
Looking forward to further suggestions.
On 2016-06-04 18:57 (+0200), Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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>
> > > 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
> > 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
> > > 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:
> > 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
> > > 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
> where %s identifies the origin of the offset value or the object that
> was expected to be located at that offset.
This is an archived mail posted to the Subversion Users mailing list.