On 04.06.2016 18:57, Daniel Shahaf 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> 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,
( and copy-from info may break as well )
> but shouldn't cause FS corruption.
You are right in that it should not directly cause an issue.
What people tend to do, however, is to put the new repo
at the same physical location as the old one and then the
server might re-use outdated information from its cache.
ATM, there is no known mechanism that will corrupt future
commits in addition of just delivering bogus results while
the cached data lasts.
That said, it is dicey and since what we have here is looks
like a new type of corruption (l2p translation appears to
have worked but the result points a few bytes outside the
valid range), I simply like to make sure ...
>>> 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.
Well, we don't always have that much context information
available but we should definitely include the valid range
etc. People are then more likely to recognize this a problem
with the internal logic.
-- Stefan^2.
Received on 2016-06-08 07:55:20 CEST