You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jack Ivey <iv...@altair.com> on 2004/05/01 14:48:24 UTC
svnadmin hotcopy problem with strings > 2G
Hi all,
Is svnadmin supposed to work with strings files larger than 2G? I
seem to be having a problem (see below). There's enough
disk space on the repository file system. /tmp doesn't have enough
space for a copy of the file, but the error message implies the
copy is directly to the target directory.
Anyone else seen this?
Also, is shutting down httpd and cp -r sufficient for a workaround?
Thanks,
Jack
# svnadmin hotcopy test1 test1bak
svn: Can't copy 'test1/db/strings' to 'test1bak/db/strings.tmp': File too
large
[root@pc233 svn]# ls -l test1/db/strings
-rw-r--r-- 1 apache cvs 2432983040 May 1 10:10 test1/db/strings
# svnadmin --version
svnadmin, version 1.0.1 (r1)
compiled Mar 12 2004, 20:34:40
Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).
# df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 35278540 15674332 17812160 47% /u2
versions:
svnadmin: 1.0.1
OS: RH8
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>.
Hi,
> The question is, if "support for large files" is an optional feature or if it
> is an alternative and how it is done.
> - If, depending on this support, a library exports a symbol "foo" with
> different interfaces, programs can fail silently when calling it. This is bad
> and should be avoided.
This is never implemented like that.
> - If, as glibc does it, it exports two versions of function "foo", one called
> foo for the standard off_t and one called "foo64" for large file off_t,
> things are fine.
That's how it's implemented on all Linux/Unix systems.
> - If, depending on the settings while building, it only exports either a
> symbol "foo" or "foo64", then a program trying to link with one version but
> expecting the other will fail, complaining that it can't find a required
> symbol. This is still acceptable because it doesn't cause silent failures,
> but if it is possible and the overhead is not too great, I'd rather always
> export both versions of a function.
I'm not sure it's possible to tweak an existing library to export one
symbol or the other depend on the link options of a program that's using
it. But anyway, that not how it works.
> This is basically what is meant in [1], under the header "LFS and libraries
> other than glibc".
>
> Note: I just said that your advice was dangerous, not that it was wrong. It
> really depends on the particular case and on the person knowing what they do.
> To be honest, I don't even know how APR does it, so it could be that your
> advice will not break things.
It's correct, and it's also not dangerous. The people who designed LFS
had of course thought about all these issues. Generally speaking, Unix
libraries don't evolve by breaking binary compatibility. If they do,
that's usually a bug. In the case of LFS, I've never heard of such a bug.
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Dimitri Papadopoulos-Orfanos wrote:
> > The solution is rather to
> > #ifdef LARGE_FILE_SUPPORT
> > # define foo foo64
> > #endif
> > void foo(off_t);
> >
> > To make programs trying to load the wrong lib fail at (dynamic-)
> > linktime. One could even have support for both then, just as glibc has.
>
> I'm not sure what you mean by wrong library, or supporting both of them.
> Which wrong library? glibc has support for both of what? I think there's
> a misunderstanding about how large file support is implemented.
The question is, if "support for large files" is an optional feature or if it
is an alternative and how it is done.
- If, depending on this support, a library exports a symbol "foo" with
different interfaces, programs can fail silently when calling it. This is bad
and should be avoided.
- If, as glibc does it, it exports two versions of function "foo", one called
foo for the standard off_t and one called "foo64" for large file off_t,
things are fine.
- If, depending on the settings while building, it only exports either a
symbol "foo" or "foo64", then a program trying to link with one version but
expecting the other will fail, complaining that it can't find a required
symbol. This is still acceptable because it doesn't cause silent failures,
but if it is possible and the overhead is not too great, I'd rather always
export both versions of a function.
This is basically what is meant in [1], under the header "LFS and libraries
other than glibc".
Note: I just said that your advice was dangerous, not that it was wrong. It
really depends on the particular case and on the person knowing what they do.
To be honest, I don't even know how APR does it, so it could be that your
advice will not break things.
cheers
Uli
[1] http://www.suse.de/~aj/linux_lfs.html (thanks for the links, btw)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>.
Hi,
>>On RH8 the native off_t is 64-bit or 32-bit depending on the compilation
>>options. So it does make sense to compile APR with "large file" support.
>
>
> This is a dangerous advice.
> Assuming a C function "void foo(off_t);", you get two different effective
> prototypes depending on the settings. However, the symbol which the linker
> sees will be called "foo", no matter what. Programs assuming 64 bit off_t
> will happily call a 32 bit foo and break silently and mysteriously.
I don't know where you got this information from. The procedure I've
described is standard procedure. All automake/autoconf projects use it
for example. See for example:
http://ftp.sas.com/standards/large.file/x_open.20Mar96.html
http://www.suse.de/~aj/linux_lfs.html
...
Depending on the compile time settings, foo actually ends up being foo64
or foo. Have a look a Unix/Linux <stdio.h> header for more information
on how it works (usually either #pragma or #define).
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>.
Hi,
> The solution is rather to
> #ifdef LARGE_FILE_SUPPORT
> # define foo foo64
> #endif
> void foo(off_t);
>
> To make programs trying to load the wrong lib fail at (dynamic-) linktime. One
> could even have support for both then, just as glibc has.
I'm not sure what you mean by wrong library, or supporting both of them.
Which wrong library? glibc has support for both of what? I think there's
a misunderstanding about how large file support is implemented.
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Dimitri Papadopoulos-Orfanos wrote:
> On RH8 the native off_t is 64-bit or 32-bit depending on the compilation
> options. So it does make sense to compile APR with "large file" support.
This is a dangerous advice.
Assuming a C function "void foo(off_t);", you get two different effective
prototypes depending on the settings. However, the symbol which the linker
sees will be called "foo", no matter what. Programs assuming 64 bit off_t
will happily call a 32 bit foo and break silently and mysteriously.
The solution is rather to
#ifdef LARGE_FILE_SUPPORT
# define foo foo64
#endif
void foo(off_t);
To make programs trying to load the wrong lib fail at (dynamic-) linktime. One
could even have support for both then, just as glibc has.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Branko Čibej <br...@xbc.nu>.
Joe Orton wrote:
>On Sat, May 01, 2004 at 09:56:50AM -0500, Ben Collins-Sussman wrote:
>
>
>>Jack Ivey wrote:
>>
>>
>>>Hi all,
>>>Is svnadmin supposed to work with strings files larger than 2G?
>>>
>>>
>>Looks like you need to compile APR with largefile support.
>>
>>
>
>That's not really a good answer for this problem (not that I'm offering
>a better one). APR 0.9.x does not have "large file" support on systems
>with a 32-bit native off_t.
>
>You *can* recompile recent versions of APR 0.9 with large file support,
>but this is really not recommended, especially not for binary packagers,
>since it creates a library with a different ABI.
>
>
So. Does that mean we're recommending _not_ to use hotcopy on 32-bit
*nix systems because APR's file handling is broken?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>.
Hi,
>>Looks like you need to compile APR with largefile support.
>
>
> That's not really a good answer for this problem (not that I'm offering
> a better one). APR 0.9.x does not have "large file" support on systems
> with a 32-bit native off_t.
On RH8 the native off_t is 64-bit or 32-bit depending on the compilation
options. So it does make sense to compile APR with "large file" support.
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sat, May 01, 2004 at 09:56:50AM -0500, Ben Collins-Sussman wrote:
> Jack Ivey wrote:
> >Hi all,
> >Is svnadmin supposed to work with strings files larger than 2G?
>
> Looks like you need to compile APR with largefile support.
That's not really a good answer for this problem (not that I'm offering
a better one). APR 0.9.x does not have "large file" support on systems
with a 32-bit native off_t.
You *can* recompile recent versions of APR 0.9 with large file support,
but this is really not recommended, especially not for binary packagers,
since it creates a library with a different ABI.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnadmin hotcopy problem with strings > 2G
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Ivey wrote:
> Hi all,
> Is svnadmin supposed to work with strings files larger than 2G?
Looks like you need to compile APR with largefile support.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org