apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: do we still want sendfile enabled with our default conf files?
Date Fri, 18 Mar 2005 10:59:55 GMT
On Thu, 17 Mar 2005 17:33:31 -0800, Justin Erenkrantz
<justin@erenkrantz.com> wrote:
> A solution that disables sendfile for OSes that do not have these sendfile
> issues (say *BSD and Solaris) are going to get my veto.  If we need to do some
> platform/run-time detection to identify those platforms that we know may be
> buggy, then we add those in.

Solaris and *BSD are the only platforms where I have no personal
knowledge of problems.

> This is the first time I can recall a thread that says sendfile is broken.
> Perhaps there's been threads and I just don't remember them.  *shrug*

lots of pain visible in bugzilla over time as well as support centers
for web servers based on Apache 2

> It's bad behavior on our part to turn off features because one or two OSes
> have problems.

a) more than one or two OSs have issues

b) it is a philosophy that says trouble-free operation is more
important than a bit of extra performance for that large portion of
our user community that doesn't choose to go tweaking the config to
server pages faster; this is a non-critical feature

>  The proper course of action should be to identify those OSes,
> and, if possible, the circumstances that cause the brokenness and have our
> code act accordingly.  In fact, I bet all of the run-time checks *could* be
> placed inside of APR's apr_socket_sendfile().  -- justin

Here are some imperfect run-time checks to add.  Some of these will
have to be  maintained over time.  For example, people will expect
that if some filesystem problem is fixed in some kernel level, we do
the right thing and stop disabling sendfile for it on that kernel

Linux/broken-ethernet-cksum-offload scenario

1) APR can't figure out if the card is putting bogus checksums on the
wire, so whatever check APR makes will have to be conservative and
will end up disabling sendfile for some cards where it really does
work.  (Maybe it decides that any sendfile on an IPv6 socket is
unsafe.)  Since APR has to allow sendfile to work when the
administrator knows it is safe, this autodetect logic will be
triggered by a special flag to apr_sendfile() --
APR_SENDFILE_AUTODETECT.  When the flag is enabled and APR decides
that the call may not be safe, APR returns ENOTIMPL or some
well-defined error.

2) Apache has the "EnableSendfile autodetect" setting that causes
APR_SENDFILE_AUTODETECT to be passed in to apr_sendfile().  For this
setting, when APR returns ENOTIMPL it turns around and calls

Now on to the Linux/broken filesystem scenario:

APR can't figure out if the filesystem really handles sendfile
correctly.  All it can do is have an array of filesystem ids which
nobody has ever had an issue with.  We'll start with ext2 and ext3 and
maybe somebody chimes in with another couple.  So it somehow finds
which filesystem owns the file and decides what to do.


Folks at HP can't state in which circumstance it fails strangely, so
always fail if the APR_SENDFILE_AUTODETECT is on.


Doesn't really fail in the normal sense of not putting the right data
on the wire, but can trigger a kernel memory issue if some kernel
tuning is incorrect.  So always fail if the APR_SENDFILE_AUTODETECT is
on.  (This kernel tuning is irrelevant unless sendfile or more obscure
TCP usage is actually occuring, so the tuning issue has typically been
there all along without hurting anything.)


Figure out if any LSP is installed.  If so, fail if

View raw message