apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: troubles dealing with APR_HAS_LARGE_FILES=0
Date Mon, 12 May 2003 21:40:01 GMT
--On Monday, May 12, 2003 15:38:52 +1000 Stas Bekman <stas@stason.org> 

> I'm trying to figure out why do I get APR_HAS_LARGE_FILES set to zero on
> my linux box. I can't find any rules that makes that decision. From
> reading archives, I understood, that it's simply unconditionally turned
> off. The most recent thread on this topic seems to be:
> http://marc.theaimsgroup.com/?t=104646080100001&r=1&w=2

Older versions of glibc do not support compilation with large files turned 
on and use of sendfile().  If you want to work in those environments, you 
have to turn off sendfile(), which most people don't want to do in a 
network-intensive application (like httpd).  For file-intensive apps (like 
perl), they don't need sendfile and would rather support large files 

I think the Linux kernel has optionally supported sendfile64 since 2.2, but 
the glibc layer doesn't expose it properly.  So, you could also bypass 
glibc and perform the syscall directly on Linux versions with sendfile64, 
but only a 32-bit sendfile().

Recent versions of glibc supposedly fix it (still only shipped in 
bleeding-edge distro releases, I think).  I think Sascha (?) posted a proof 
of concept that would detect newer glibc's or do the syscall itself, but it 
wasn't a concrete patch, IIRC.  Still, you'd have to disable sendfile() 
with large files when you see an older glibc and no sendfile64 (which I 
think is a bad idea to do by default).

If you'd like to take that proof of concept and create a patch that we 
could apply, it'd be welcome.  -- justin

View raw message