[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#494768: confirming that this is still a problem for apache serving from a CIFS mounts on lenny



Hi,

On Wed, 25 Mar 2009, Daniel Kahn Gillmor wrote:

I can verify that apache2-mpm-worker is indeed having this problem when
serving static files from a CIFS mount on a modern lenny system.

I don't deny this and it is certainly not optimal, but it works as documented. I have poked upstream about it but I don't expect that it
changes in the near future.

I agree with Bastian Blank that it seems like Apache is misbehaving
here.  If sendfile(2) fails, shouldn't apache gracefully fall back to
non-sendfile behavior (based on the number of bytes transferred, which
should be in the *offset parameter).

sendfile(2) even says:

      Applications  may  wish  to  fall  back to read(2)/write(2) in
      the case where sendfile() fails with EINVAL or ENOSYS.

It also says:

CONFORMING TO
       Not specified in POSIX.1-2001, or other standards.

       Other  Unix  systems  implement  sendfile()  with  different
       semantics and prototypes.  It should not be used in
       portable programs.

Apache needs to be portable. Maybe sendfile's error reporting does not work reliable on other plattforms.

Interestingly, when i tried experimenting with this by doing sendfile
from a CIFS-mounted file through a local UNIX-domain socket [0],
sendfile(2) returned EOVERFLOW, but the entire file transferred cleanly,
even for a ~5MB file.

This would show that it is not so easy to determine where to continue when something went wrong. Interestingly, EOVERFLOW is not a valid error code for sendfile according to my version of sendfile(2) :-/

Cheers,
Stefan



Reply to: