Re: svn commit: r589910 - in /apr/apr/trunk: CHANGES configure.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Before I backport, I want to quickly test the temperature of the list...

wrowe@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=589910&view=rev
> Log:
> Radical change that corrects a horrible misassumption; the feature
> APR_HAS_LARGE_FILES means that we support offsets larger than memory
> could contain.  An audit of the code reveals no functional changes
> in the compilation of the library.  The testlfs.c source proves that
> this is the assumption of the users of this 'undocumented feature'.
> 
> In fact, it's not possible to properly determine this publicly to
> adjust testlfs.c based on any other public symbol from the library.

If you study testlfs.c, we assume an 8gb file is nothing but an aspect
of having APR_HAS_LARGE_FILES.  Fine, that's what I always assumed too.
Win32 explicitly defined this forever because we use >size_t apr_off_t's.

Unix obviously failed to do this forever, and many platforms have never
tested testlfs.c, rendering that test bogus.

>  Changes for APR 1.3.0
>  
> +  *) Corrected for Darwin and others to toggle APR_HAS_LARGE_FILES
> +     where large off_t's are enabled without any extra defines, hints
> +     or additional functions.  This is binary compatible, but apps
> +     may need to be recompiled to take full advantage depending on how
> +     they detect this feature.  [William Rowe]
> +

> --- apr/apr/trunk/configure.in (original)
> +++ apr/apr/trunk/configure.in Mon Oct 29 16:32:59 2007
> @@ -1413,6 +1413,10 @@
>      # Enable LFS
>      aprlfs=1
>      AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
> +elif test "${ac_cv_sizeof_off_t}" != "${ac_cv_sizeof_size_t}"; then
> +    # unsure of using -gt above is as portable, can can't forsee where
> +    # off_t can legitimately be smaller than size_t
> +    aprlfs=1
>  else

are we ok with this implementation or do folks have better ideas?

Finally, testlfs.c itself, now that we can (generally) compute CSIZE
everywhere, would let us test if a small sample test file of 1siMB + 1
byte actually occupies that much space, and bail if not.  If the CSIZE
becomes 2siMB or greater, we should further assume that this is a silly
FS that probably does provide sparse allocation but who's storage mult
is so large we won't measure it.

If that test sounds rational, this could become APR_HAS_SPARSE_FILES for
apr 1.3.0 only.

Both win32 previously, and darwin 9 now using HFS+, suck up 8GB of real
storage, which is (obviously) not acceptable - it's gotta be fixed before
we tag and roll 1.2.x.

Bill

Re: svn commit: r589910 - in /apr/apr/trunk: CHANGES configure.in

[Joe Orton <jo...@redhat.com>]

On Mon, Oct 29, 2007 at 07:14:45PM -0500, William Rowe wrote:
> Before I backport, I want to quickly test the temperature of the list...
> 
> wrowe@apache.org wrote:
> >URL: http://svn.apache.org/viewvc?rev=589910&view=rev
> >Log:
...
> 
> >--- apr/apr/trunk/configure.in (original)
> >+++ apr/apr/trunk/configure.in Mon Oct 29 16:32:59 2007
> >@@ -1413,6 +1413,10 @@
> >     # Enable LFS
> >     aprlfs=1
> >     AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
> >+elif test "${ac_cv_sizeof_off_t}" != "${ac_cv_sizeof_size_t}"; then
> >+    # unsure of using -gt above is as portable, can can't forsee where
> >+    # off_t can legitimately be smaller than size_t
> >+    aprlfs=1
> > else
> 
> are we ok with this implementation or do folks have better ideas?

This will break at least mod_perl, I don't see how it's a good idea, or 
why it's even necessary.  Why change it?  Just so some tests run on more 
platforms?  That is achievable by tweaking some #defines in testlfs.c.

APR_HAS_LARGE_FILES has meant on Unix for the lifetime of 1.x "apr_off_t 
larger than native off_t".

joe

Re: svn commit: r589910 - in /apr/apr/trunk: CHANGES configure.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

William A. Rowe, Jr. wrote:
> 
> Finally, testlfs.c itself, now that we can (generally) compute CSIZE
> everywhere, would let us test if a small sample test file of 1siMB + 1
> byte actually occupies that much space, and bail if not.  If the CSIZE
> becomes 2siMB or greater, we should further assume that this is a silly
> FS that probably does provide sparse allocation but who's storage mult
> is so large we won't measure it.

And I should have pointed out, if APR_FINFO_CSIZE isn't in .valid, well
then, it's too broken a platform to trust making an 8gb file, no?  So if
we don't get a csize out of a basic stat, we'll just bail.

> If that test sounds rational, this could become APR_HAS_SPARSE_FILES for
> apr 1.3.0 only.

Gets trickier to combine the test in an autoconf macro, where we don't
have apr_file_stat yet.