UNIX has actual physical limits to file size determined by the number of bytes 
a 32 bit file pointer can index, about 2.4 GB. for older file systems or 
runtimes.

Depending on your system, you may or may not have large file support. Try

 man fopen64

if you have an older UNIX.

Cheers,
 
Tom Loy


-----Original Message-----
From: Jeremy Conlin [mailto:jlcon...@gmail.com] 
Sent: Tuesday, January 19, 2010 3:22 PM
To: Thomas Loy
Cc: users@subversion.apache.org
Subject: Re: svn dump and load not preserving all files

On Tue, Jan 19, 2010 at 1:05 PM, Thomas Loy <thomas....@cbeyond.net> wrote:
> Which OS?  Some operating systems have file size limits of 4 GB or less.
>
> Cheers,
>
> Tom Loy
>
The original OS was on a Mac, the new OS is some *nix server, probably
Linux.  I don't believe either of these have limitations as small as
4GB.  Am I wrong?

Thanks,
Jeremy


>
> -----Original Message-----
> From: Jeremy Conlin [mailto:jlcon...@gmail.com]
> Sent: Tuesday, January 19, 2010 3:03 PM
> To: users@subversion.apache.org
> Subject: svn dump and load not preserving all files
>
> I am migrating my repository to a new server.  This requires that I
> dump the original and the create a new repository on the new server
> and use the svnadmin load command to import everything.  I have been
> able to do this for a few of my repositories, but one in particular
> isn't working.  The dump file for this repository is > 9 GB.  The load
> command starts out, but never finishes.  The size of my repository
> gets to 2.1 GB and then it seems to stop even though the svnadmin load
> command is still running.  Eventually (> 24 hours) the command stops
> (finishes) but the size of my repository is only 2.1 GB when it should
> be around 9 GB.  Also, not all of the files have been restored.
>
> Is there a limit in the size of a dump file that can be used?  I would
> be surprised if that limit were around 9 GB.  I'm sure there are
> repositories that are much larger than that.
>
> Any ideas on what could be wrong?
>
> Thanks,
> Jeremy
>

Reply via email to