On Thu, May 04, 2006 at 10:26:56AM +0200, Niklas Edmundsson wrote:
> On Thu, 4 May 2006, Joe Orton wrote:
> >OK, what filesystem? Colm had reported the same thing on Debian/IA64,
> >which was on an NFS mount, IIRC. If you adjust apr_brigade_insert_file
> >to only allow buckets of MAX_BUCKET_SIZE regardless, i.e. change the
> >conditional to:
>
> This was on XFS and on an NFS mount. It should be noted that this
> works on a 32bit (also Ubuntu Breezy) machine with identical config.
Can you try it on a local ext3 filesystem?
At what file size does it start failing like this?
...
> To me this looks like you'll get sendfile instead of sendfile64 unless
> you have asked for LFS-stuff, even on a 64bit platform.
Ignore that stuff. sendfile64() is not needed on 64-bit platforms, the
normal sendfile() takes an off_t which is already 64-bit. sendfile64 is
needed on 32-bit platforms where the native off_t is 32-bit and APR is
using off64_t instead.
> > if (length < MAX_BUCKET_SIZE) {
> >
> >does that work?
>
> It probably won't since this seems to be an issue of using sendfile
> instead of sendfile64 since it's the sendfile syscall returning EINVAL
> and not apr.
Assuming that sendfile works for small files, I am guessing that this is
a kernel (or fs-specific) problem with passing large (>2Gb?) count
values. If you change the code as I indicate that will ensure that
sendfile() is never used with a >1Gb count value, which should test that
hypothesis. It it does fail please include some strace output to ensure
the sendfile() call is failing at the same point. (and not e.g. when
the offset value grows to >2Gb).
joe
