Re: fsfs migration failure. File too large??

[Bryn Davies <cu...@progsoc.uts.edu.au>]

 Hi Everyone.

 The thread about Tess' problems with FSFS migration was brought to my 
attention, and I exchanged a few mails with Ben on what I thought the 
problem might be.  As I seem to be committed to seeing this through to 
it's gory conclusion, I've signed on to the list and will repost
what we discussed here, in case anyone else can throw in their two cents.
I'm a bit of a newbie, so feel free to rip it to bits.

 This is the condensed version. ;-)

 APR_LARGEFILE - flag for apr_file_open

 The older builds of SVN don't seem to use this flag, which was added to APR's 
apr_file_open by Joe Orton back in 0.9.4-??.  The latest cut I'm aware of 
( 1.2.0 ) uses it for copy_db_file_safely, but nowhere else, as far as I'm
aware.  Ben has brought this up on the dev@ list, and it was pointed out
by another poster that slathering APR_LARGEFILE on liberally is not a panacea 
for these problems, as the older 0.9.6 APR's define the type apr_seek_where_t
as an int... to follow POSIX, I guess.  Unfortunately, I think off_t has been
a minimum of 64 bits wide since unix98. 

 If SVN was amended to use APR_LARGEFILE, we'd be able to open, read and 
write large files, but not seek around inside them.  I'm told this is a 
dealbreaker for fsfs.  

 The solution I envision as involving the minimal amount of bloodshed right
now would be to take the distribution of apr included with subversion, change
it to use off_t for apr_seek_where_t where it's available, print warnings 
where it isn't, and force the use of O_LARGEFILE to open, where it's defined.
( This last bit runs against the LFS coding specifications, but at this point,
who cares.  It's the legacy tree anyway. )  People would have to build SVN
against this copy of apr.

 I am happy to attempt to try and write the patch tonight, but the big 
question is, do people think it will cover all the problems?  Will it work?  
Etc??

 One last troubling thing is that I shot over to a friends linux box to have
a fiddle with this stuff, and found out that fnctl.h wasn't defining 
O_LARGEFILE on his system, even though manually inserting the bitmask into
the flags for open(2) worked fine.  Digging in include/bits/fnctl.h
shows that it's only defined if __USE_LARGEFILE64 is defined in turn.  We
don't have the concept of O_LARGEFILE on darwin, so I'm a bit uncertain
about all this.  Would it be prudent to define the flag ourselves?  Can
a linux guru advise me on this?

 Let me know what you think,
  Bryn.

-- 
"There were too many of us. We had access to too many, uh, too much money.
 Too much equipment... and little by little we went insane."

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: fsfs migration failure. File too large?? - Speculative Fix Attached

[Bryn Davies <cu...@progsoc.uts.edu.au>]

 Well, here are my patches to APR 0.9 and Subversion 1.0.9 to enable  
full 64 bit file sizes.  I wrote these patches in a text mode install  
of Ubuntu running on emulated x86 on a 1.25ghz PowerPC running  
MacOSX.  It was a _trail_of_tears_.  Since I don't have a failing svn  
case to test it with, I've been using a test program that does the  
following using the APR library functions - opens a file, writes 3G  
to it, and then seeks around inside and checks to see if the returned  
offset is still sane.  Pleasingly, it seems to be.

  I haven't tested this on anything except simulated x86 Linux.  I  
didn't test it with Buffered IO, because I don't think SVN uses it.   
If anyone can let me know if it fixes their problem, that'd be great,  
but I'm not really enthusiastic about recommending it until someone  
double checks it for me.  I don't want the blood of any corrupted  
repositories on my hands.

  Build procedure is:
     * tar xvfz subversion-1.0.9.tar.gz
     * cd subversion-1.0.9/apr
     * patch -p1 < ( apr patch )
     * autoconf
     * ./configure --enable-largefile
     * make
     * cd ../subversion
     * patch -p2 < ( subversion patch )
     * ./configure etc etc as normal.

  Hope it's of some use to someone.

  Bryn.

Re: fsfs migration failure. File too large??

[Bryn Davies <cu...@progsoc.uts.edu.au>]

On 01/06/2005, at 4:43 PM, Bryn Davies wrote:
>  I think _that_ problem is addressed by making APR open all it's files
> with O_LARGEFILE.  Of course, just tacking APR_LARGEFILE everywhere
> won't help unless O_LARGEFILE was defined in APR at compile time - it
> uses this as the gate condition for including the flag, not
> _LARGEFILE_SOURCE as you might expect.

  Progress update:

  First, I was wrong to natter on about apr_seek_where_t being  
incorrectly sized.  apr_seek_where_t is actually the 'whence'  
parameter to lseek, not the offset itself.  I must have looked at  
this code six or seven times before sending those last letters, and  
made the same mental mistake each time.  Sometimes I wonder how I  
dress myself every morning.  The problem with seeking was actually  
down to the sizing of apr_off_t ( which in retrospect seems like,  
"duh" ).  Fortunately, I have found the configuration parameter that  
seems to control this - APR_HAS_LARGE_FILES inside apr.h.in.  The bad  
news is, this seems to in most cases end up being off_t afterall,  
which is subject to shapeshifting on linux and Solaris.

  You can see in apr.hw ( the windows apr.h ) that apr_off_t actually  
gets redefined to __int64 if APR_HAS_LARGE_FILES is on, but  
APR_HAS_LARGE_FILES seem to have no other effect.  Looks like it's  
back to the configure.in drawing board for me.

  I have half of a patch written which puts the Largefile Autoconf  
macro's into the apr configure.in, which can then be used with -- 
enable-largefile, but on Linux these macros for some reason don't  
define -D_FILE_OFFSET_BITS=64 in the cflags, which is neccessary to  
get a correct off_t size.  I was experimenting with this on my  
friends linux machine when it suddenly ran out of process handles and  
died horribly.  I may have to see if I can pick up development using  
qemu and knoppix or something.

  I wrote a little test program to check if things were working  
properly, I don't know APR so it's probably stylistically ghastly.   
I'm just going to chuck it on here if people want to test if their  
APR's handle large files gracefully.

  Bryn.

Re: fsfs migration failure. File too large??

[Bryn Davies <cu...@progsoc.uts.edu.au>]

On Tue, May 31, 2005 at 09:45:59PM -0700, Garrett Rooney wrote:
> Why not just compile a version of APR that has the problem fixed by 
> making apr_off_t larger (APR 1.x has the fix, Subversion uses APR 0.9.x, 
> for binary compat reasons, not because 1.x won't work or something).

 I don't think this addresses the problem that this user was seeing
though - it addresses a distinct but related one.  Trying to stuff a 64
bit off_t into the int provided by APR just ends up with an overflowed
int, wrapped around into the negatives.  I think negative offsets are
legal to lseek when used in conjunction with, say, SEEK_CUR.  It doesn't 
raise SIGXFSZ, that's for sure.

 I think _that_ problem is addressed by making APR open all it's files
with O_LARGEFILE.  Of course, just tacking APR_LARGEFILE everywhere
won't help unless O_LARGEFILE was defined in APR at compile time - it
uses this as the gate condition for including the flag, not
_LARGEFILE_SOURCE as you might expect.  

 Sekrit Research (TM) has revealed this to be finally dependent ( on Linux 
at least ) on stuff defined in /usr/include/features.h, namely
_LARGEFILE_SOURCE and _LARGEFILE64_SOURCE.  This is what I suspect
I was doing wrong when I tried to patch SVN on my friends machine
last night.  I am puzzled as to why getconf LFS_CFLAGS doesn't
include this deadly duo.

 So yeah.  Build APR with those two defines, use APR_LARGEFILE in the
application, and either backport 64 bit file offsets, or use APR 1.x.
And then it _should_ all work.  I think.

 B.

-- 
"There were too many of us. We had access to too many, uh, too much money.
 Too much equipment... and little by little we went insane."

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: fsfs migration failure. File too large??

[Garrett Rooney <ro...@electricjellyfish.net>]

Bryn Davies wrote:

>  The solution I envision as involving the minimal amount of bloodshed right
> now would be to take the distribution of apr included with subversion, change
> it to use off_t for apr_seek_where_t where it's available, print warnings 
> where it isn't, and force the use of O_LARGEFILE to open, where it's defined.
> ( This last bit runs against the LFS coding specifications, but at this point,
> who cares.  It's the legacy tree anyway. )  People would have to build SVN
> against this copy of apr.
> 
>  I am happy to attempt to try and write the patch tonight, but the big 
> question is, do people think it will cover all the problems?  Will it work?  
> Etc??

Why not just compile a version of APR that has the problem fixed by 
making apr_off_t larger (APR 1.x has the fix, Subversion uses APR 0.9.x, 
for binary compat reasons, not because 1.x won't work or something).

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org