Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
Message-ID: <pony-2877b7487b187b220c3aefb24550cb55e3514ddb-3de181d3e5e2fc39f8494bba1bd626e794f41a6c@users.subversion.apache.org>
Subject: Re: "Offset too large" error when packing repository in FSFS 7 format
References: <48a61c1eae5637915160adf7f1be4955@mail.gmail.com> 
From: "Stefan Fuhrmann"<stefan2@apache.org>
In-Reply-To: <48a61c1eae5637915160adf7f1be4955@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 04 Jun 2016 08:04:42 -0000
To: <users@subversion.apache.org>
archived-at: Sat, 04 Jun 2016 08:04:50 -0000


On 2016-06-03 09:36 (+0200), Radek Krotil <radek.krotil@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?

> 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. Subversion is likely to run out of memory
before hitting any repo format limitations.

> The mentioned revision seems to be a result of an user error. It resulted
> in adding 169,200 paths to the repository. The delta file of the revision
> 5102 is 394141477 B. Subversion 1.9.3 was used when performing this
> operation on CentOS 7.2. FSFS 7 backed uses default configuration
> (therefore deltification is used).

By "delta file" you mean the revision file (deb/revs/5/5102)?

If so, could you run a 'grep -oba L2P-INDEX 5102' on it
and post the results here?

How many revisions did the repo have before the
conversion?

> Originally, the repository was stored in FSFS 6 format with default
> settings (no deltification). Packing the repository in old format finished
> successfully and the pack file size was about 831 MB.

If the old repository still available, please re-run
the sump/load cycle to see whether the problem
is reproducible. Keep your current FSFS7 repo, too.

> Looking forward to hearing any guidance how to configure my backend so that
> I can eventually pack the repository in the new format.

My current best guess is that something interfered
with 'svnadmin load' process.

-- Stefan^2.