[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Error E140001: Sum of subblock sizes larger than total block content length

From: Ronald Taneza <ronald.taneza_at_gmail.com>
Date: Tue, 21 Nov 2017 15:43:43 +0100

Hi,

I got the error below while running "svnadmin load -M 0" to load a dump
file created by "svnrdump dump".

  svnadmin: E140001: Sum of subblock sizes larger than total block content
length

This error was reported when "svnadmin load" was loading a big file (around
2 GB) from a revision in the dump file.
I checked the dump file produced by svnrdump, and noticed that the
Content-length for the 2GB file is a negative value! (see below)

I finally got it working by first creating a local dump file using
"svnadmin dump", then loading this dump file using the same "svnadmin load"
command used above.

More details below:
We are migrating our subversion server from Ubuntu Linux to Window Server
2012.
* Current server (Linux): svn, version 1.9.3 (r1718519)
* New server (Windows): svn, version 1.8.19 (r1800620)

We are actually using an older svn version in the new Windows server,
because we are using CollabNet Subversion Edge, which still uses the svn
1.8 series.

To migrate data, we have a script running in the new server that does:
* svnrdump dump https://current-server/repo --incremental > dumpfile
* svnadmin load -M 0 local-path\repo < dumpfile

The "svnadmin load" command failed with the error message above, when
loading a revision containing a big file (around 2 GB).
Checking the dump file produced by svnrdump (svn version 1.8.19), I noticed
that the Content-length for the 2GB file is a negative value!
The expected Content-length value is (prop-content length +
text-content-length) = 2238208388.
But the actual value is -2056758908, which is what you get when you try to
interpret 2238208388 as a signed 32-bit integer (max 2147483647).

  SVN-fs-dump-format-version: 3

  Node-path: TheBigFile
  Node-kind: file
  Node-action: add
  Prop-delta: true
  Prop-content-length: 59
  Text-delta: true
  Text-content-length: 2238208329
  Text-content-md5: d2f79377abb0db99b37460c8156727fb
  Content-length: -2056758908

When the same revision is dumped using "svnadmin dump" in the Linux server
(svn version 1.9.3), the content-length is a positive value, as expected:

  SVN-fs-dump-format-version: 2

  Node-path: TheBigFile
  Node-kind: file
  Node-action: add
  Text-content-md5: d2f79377abb0db99b37460c8156727fb
  Text-content-sha1: 5f5c06f734f394697f90cfab26dee5d820216ee5
  Prop-content-length: 59
  Text-content-length: 2237924210
  Content-length: 2237924269

Lastly, I tried "svnrdump dump" in the Linux server (svn version 1.9.3),
and the content-length is also correct:

  SVN-fs-dump-format-version: 3

  Node-path: TheBigFile
  Node-kind: file
  Node-action: add
  Prop-delta: true
  Text-delta: true
  Text-content-md5: d2f79377abb0db99b37460c8156727fb
  Prop-content-length: 59
  Text-content-length: 2238208329
  Content-length: 2238208388

So this seems to be a problem with svnrdump version 1.8.x?

Of course, we would prefer to use the latest svn 1.9.x version, but we find
the CollabNet Subversion Edge package quite useful (apache2 and svn in one
installer package; provides web-based management console).

Regards,
Ronald
Received on 2017-11-21 15:46:35 CET

This is an archived mail posted to the Subversion Users mailing list.