On Nov 1, 2007, at 6:08 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
We don't test sendfile by default. Within APR (trunk), simply...
$ cd test
$ make
$ ./sendfile server &
$ ./sendfile client blocking
and you'll see how either the kernel library or the implementation
(or maybe even the test) is broken.
Or (and I should have seen the possibility earlier) an interop flaw
based
on CPU or filesystem. So for the record, the failure I quoted
before about
119880 bytes into the stream was on a journaled, hfs filesystem
running on
the G4, retail not server.
Correction, faults at 119980 bytes into the stream, and I just
reproduced the
flaw on journaled, ufs.
I didn't understand what you meant before, but now I'm seeing the
problem.
It appears that apr_socket_sendfile() (and probably the underlying lib
or syscall) is updating the &len value-return parameter with the size
of the file PLUS the size of the trailers. I added some debugging
output to see what's going on and here's what I got on the client side:
Creating a test file...
Sending the file...
headers[0] size 15
headers[1] size 5
headers[2] size 80000
total headers length 80020
trailers[0] size 19
trailers[1] size 10
trailers[2] size 90000
total trailers length 90029
total iov length 170049
calling apr_socket_sendfile() with len 200000
apr_socket_sendfile() updated offset with 0
apr_socket_sendfile() updated len with 290029
bytes really sent: 370049
apr_socket_sendfile() didn't report the correct number of bytes sent!
As you can see, the returned len == 290029, which is the same as the
file size (200000) + the trailers size (90029). If the syscall is
returning this then it's a kernel bug since it's a change in the
Darwin sendfile semantics.
Now I'll see if I can get this fancy new dtrace stuff to report the
syscall results...
-aaron
