On Thu, 17 Mar 2005 17:33:31 -0800, Justin Erenkrantz <[EMAIL PROTECTED]> 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 level. 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 emulate_sendfile(). 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. HP-UX: Folks at HP can't state in which circumstance it fails strangely, so always fail if the APR_SENDFILE_AUTODETECT is on. AIX: 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.) Windows: Figure out if any LSP is installed. If so, fail if APR_SENDFILE_AUTODETECT is on.
