You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2005/03/18 11:59:55 UTC
Re: do we still want sendfile enabled with our default conf files?
On Thu, 17 Mar 2005 17:33:31 -0800, Justin Erenkrantz
<ju...@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
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.
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 12:20 PM -0500 Jeff Trawick <tr...@gmail.com>
wrote:
> google does; keywords "ntfs" "smbfs" and some other "UDF" ("Universal
> Disk Format (UDF) ", which I've never heard of
"ntfs sendfile freebsd" 2nd hit on Google is a patch I sent to FreeBSD lists
years ago about a sendfile() problem in ftpd. =)
> I don't see any checks in APR by FreeBSD-using developers to try to
> figure out if the file being served just might not be served properly
> due to filesystem problems.
There are already autoconf checks and run-time version checks for FreeBSD
sendfile() issues. Yes, there aren't any run-time checks based on
filesystems, but that's just never been brought up.
> I don't understand where you're coming from on this "brain dead"
> "buggy OS" crap.
> Every OS is a complete PITA at one point or another. It is not a
> constructive talking point. We're beyond that and are trying to find
> a practical way to avoid some pain for our users.
All I'm saying is that we should put forth a solid effort to have APR deal
with these cases as best as we can rather than forcing the admin to know the
details of their operating system. In fact, I think I'm displaying more
sympathy to the admins than 'we can't help you - you need to guess'. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 18 Mar 2005 08:59:43 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:51 AM -0500 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> > ouch, add one more brain-dead OS to the list: FreeBSD; some levels
> > have had filesystems which don't handle sendfile correctly (same type
> > of issue which hits some Linux users)
>
> Do you have details? FreeBSD's sendfile was broken for some versions (i.e.
> <4.10 with threading). We already have configure checks in APR for some of
> this.
google does; keywords "ntfs" "smbfs" and some other "UDF" ("Universal
Disk Format (UDF) ", which I've never heard of
> I find it amusing that Linux-centric developers
do we need to take a poll? ("SunOS sol10 5.10 Generic i86pc i386 i86pc")
> feel special in that they
> should disable things across the board because their OS has a bug while the
> FreeBSD-using developers just add in checks to isolate the issue on their
> platform. =) -- justin
I don't see any checks in APR by FreeBSD-using developers to try to
figure out if the file being served just might not be served properly
due to filesystem problems.
I don't understand where you're coming from on this "brain dead"
"buggy OS" crap.
Every OS is a complete PITA at one point or another. It is not a
constructive talking point. We're beyond that and are trying to find
a practical way to avoid some pain for our users.
Re: do we still want sendfile enabled with our default conf
files?
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 11:23 AM 3/18/2005, Justin Erenkrantz wrote:
>I absolutely refuse to punish users who are using good OSes because
>some OSes are brain-dead. This is exactly the role that APR is
>meant to fill
>
>Feel free to advocate Linux always returning APR_ENOTIMPL for
>sendfile - I don't care. However, blocking sendfile on non-buggy
>OSes is not a solution that I am willing to sign off on. -- justin
Isn't this about a change to not enable sendfile in the default HTTPd
config, not a change to APR to disable sendfile? In that case, this
won't affect existing HTTPd users, because they already have it
enabled in their config, and the default config never replaces an
existing config.
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 11:51:22AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 7:44 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
> >>either lacklist or whitelist fstypes per OS, I don't much care. And, we
> >>can check for IPv6 sockets on Linux.
> >
> >This is still unfair on admins. Some network cards work fine, why
> >shouldn't their owners get the benfits of sendfile?
>
> Those cases they can explicitly use 'EnableSendfile on'. IIRC, you're the
> one who said most network cards are broken with IPv6 and sendfile on Linux.
If they can still use "EnableSendfile On", then I've nothing to argue
about.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 11:51:22AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 7:44 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
> >>either lacklist or whitelist fstypes per OS, I don't much care. And, we
> >>can check for IPv6 sockets on Linux.
> >
> >This is still unfair on admins. Some network cards work fine, why
> >shouldn't their owners get the benfits of sendfile?
>
> Those cases they can explicitly use 'EnableSendfile on'. IIRC, you're the
> one who said most network cards are broken with IPv6 and sendfile on Linux.
If they can still use "EnableSendfile On", then I've nothing to argue
about.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 7:44 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
>> either lacklist or whitelist fstypes per OS, I don't much care. And, we
>> can check for IPv6 sockets on Linux.
>
> This is still unfair on admins. Some network cards work fine, why
> shouldn't their owners get the benfits of sendfile?
Those cases they can explicitly use 'EnableSendfile on'. IIRC, you're the one
who said most network cards are broken with IPv6 and sendfile on Linux.
The issue here is to be more sane with our default behavior than we are today.
I think Jeff's patch with a switch in our default httpd.conf to
'EnableSendfile autodetect' will resolve most people's concerns while
attempting to allow platforms that have straightforward (or non-expensive)
checks to still use sendfile(). -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 7:44 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
>> either lacklist or whitelist fstypes per OS, I don't much care. And, we
>> can check for IPv6 sockets on Linux.
>
> This is still unfair on admins. Some network cards work fine, why
> shouldn't their owners get the benfits of sendfile?
Those cases they can explicitly use 'EnableSendfile on'. IIRC, you're the one
who said most network cards are broken with IPv6 and sendfile on Linux.
The issue here is to be more sane with our default behavior than we are today.
I think Jeff's patch with a switch in our default httpd.conf to
'EnableSendfile autodetect' will resolve most people's concerns while
attempting to allow platforms that have straightforward (or non-expensive)
checks to still use sendfile(). -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 10:34:36AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> >I think it's just one of those cases where it would be highly
> >non-trivial and inefficient to put all of the checks in APR, simply due
> >to the real-world nature of the bugs, but that at the same time there is
> >a clear benefit available to those willing to take the time to read the
> >manual and decide for themselves if it will work in their situation.
>
> For those OSes that have a large number of cases where sendfile() doesn't
> work, then we can disable sendfile() rather than checking for these cases.
I'm not sure what you mean here, if you mean that APR won't support
sendfile then I disagree - as this prevents admins who may have
perfectly functional setups from using it. If you mean set
EnableSendfile to off by default on these platforms - then we have
nothing to argue about :)
> However, your position mandates that the admins must do a lot of legwork to
> understand if their OS has issues or not. It's not always obvious what the
> corner cases are here: I'm in favor of placing that work in APR - where
> there are people willing to produce appropriate patches to relax the
> restrictions on that OS.
I don't think its too much legwork. If an admin sees
# EnableSendfile on
in the config, it's pretty likely they'll read the manual before they
uncomment it - and there's some pretty clear advise in the manual as
to when it might break things. If admins are enable features at random
well they diserve any brokenness they get :)
> One fstatfs call will allow us to detect the FS issues we've seen:
One fstatfs call - *per request*. With statfs, you can reduce the number
of calls by maintaining a cache, and check this per request - though
this might break with remounts. Not all files need live on the same
filesystem. Regardless, either way it seems a bit ridiculous when the
point of sendfile is to *reduce* what you're doing in userspace.
> either lacklist or whitelist fstypes per OS, I don't much care. And, we can
> check for IPv6 sockets on Linux.
This is still unfair on admins. Some network cards work fine, why
shouldn't their owners get the benfits of sendfile?
> Ideally, we'd have some way of minimizing the need for fstatfs calls,
> but even without a cache of some sort (I don't know how slow or fast
> fstatfs tends to be), that's a fair price to pay for correctness and a
> viable attempt to maintain zero-copy performance.
See above :)
> Yet, I believe most of these are outright OS or driver bugs that will,
> over the long run, be fixed upstream. If your OS or driver
> maintainers don't fix problems with their software, then you have
> other issues. -- justin
Indeed.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 10:34:36AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> >I think it's just one of those cases where it would be highly
> >non-trivial and inefficient to put all of the checks in APR, simply due
> >to the real-world nature of the bugs, but that at the same time there is
> >a clear benefit available to those willing to take the time to read the
> >manual and decide for themselves if it will work in their situation.
>
> For those OSes that have a large number of cases where sendfile() doesn't
> work, then we can disable sendfile() rather than checking for these cases.
I'm not sure what you mean here, if you mean that APR won't support
sendfile then I disagree - as this prevents admins who may have
perfectly functional setups from using it. If you mean set
EnableSendfile to off by default on these platforms - then we have
nothing to argue about :)
> However, your position mandates that the admins must do a lot of legwork to
> understand if their OS has issues or not. It's not always obvious what the
> corner cases are here: I'm in favor of placing that work in APR - where
> there are people willing to produce appropriate patches to relax the
> restrictions on that OS.
I don't think its too much legwork. If an admin sees
# EnableSendfile on
in the config, it's pretty likely they'll read the manual before they
uncomment it - and there's some pretty clear advise in the manual as
to when it might break things. If admins are enable features at random
well they diserve any brokenness they get :)
> One fstatfs call will allow us to detect the FS issues we've seen:
One fstatfs call - *per request*. With statfs, you can reduce the number
of calls by maintaining a cache, and check this per request - though
this might break with remounts. Not all files need live on the same
filesystem. Regardless, either way it seems a bit ridiculous when the
point of sendfile is to *reduce* what you're doing in userspace.
> either lacklist or whitelist fstypes per OS, I don't much care. And, we can
> check for IPv6 sockets on Linux.
This is still unfair on admins. Some network cards work fine, why
shouldn't their owners get the benfits of sendfile?
> Ideally, we'd have some way of minimizing the need for fstatfs calls,
> but even without a cache of some sort (I don't know how slow or fast
> fstatfs tends to be), that's a fair price to pay for correctness and a
> viable attempt to maintain zero-copy performance.
See above :)
> Yet, I believe most of these are outright OS or driver bugs that will,
> over the long run, be fixed upstream. If your OS or driver
> maintainers don't fix problems with their software, then you have
> other issues. -- justin
Indeed.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Brian Akins <ba...@web.turner.com>.
Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> One fstatfs call will allow us to detect the FS issues we've seen:
> either blacklist or whitelist fstypes per OS, I don't much care. And,
> we can check for IPv6 sockets on Linux.
As long as I can say "EnableSendfile On," and it tries to use sendfile,
I don't care. I have a "stange" setup that I tested to ensure that
sendfile works perfectly, so the last thing I want is APR to decide it's
smarter than me and decided to turn it off when I say use it.
BTW, sendfile works fine for us with linux and ipv6. I tested and
turned off some offloading features of our cards. If someone doesn't
want to take the time to test, then they probably don't care what APR
does. As for me, if I say "on" I mean "on."
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: do we still want sendfile enabled with our default conf files?
Posted by Brian Akins <ba...@web.turner.com>.
Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> One fstatfs call will allow us to detect the FS issues we've seen:
> either blacklist or whitelist fstypes per OS, I don't much care. And,
> we can check for IPv6 sockets on Linux.
As long as I can say "EnableSendfile On," and it tries to use sendfile,
I don't care. I have a "stange" setup that I tested to ensure that
sendfile works perfectly, so the last thing I want is APR to decide it's
smarter than me and decided to turn it off when I say use it.
BTW, sendfile works fine for us with linux and ipv6. I tested and
turned off some offloading features of our cards. If someone doesn't
want to take the time to test, then they probably don't care what APR
does. As for me, if I say "on" I mean "on."
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> I think it's just one of those cases where it would be highly
> non-trivial and inefficient to put all of the checks in APR, simply due
> to the real-world nature of the bugs, but that at the same time there is
> a clear benefit available to those willing to take the time to read the
> manual and decide for themselves if it will work in their situation.
For those OSes that have a large number of cases where sendfile() doesn't
work, then we can disable sendfile() rather than checking for these cases.
However, your position mandates that the admins must do a lot of legwork to
understand if their OS has issues or not. It's not always obvious what the
corner cases are here: I'm in favor of placing that work in APR - where there
are people willing to produce appropriate patches to relax the restrictions on
that OS.
One fstatfs call will allow us to detect the FS issues we've seen: either
blacklist or whitelist fstypes per OS, I don't much care. And, we can check
for IPv6 sockets on Linux. Ideally, we'd have some way of minimizing the need
for fstatfs calls, but even without a cache of some sort (I don't know how
slow or fast fstatfs tends to be), that's a fair price to pay for correctness
and a viable attempt to maintain zero-copy performance.
Yet, I believe most of these are outright OS or driver bugs that will, over
the long run, be fixed upstream. If your OS or driver maintainers don't fix
problems with their software, then you have other issues. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> I think it's just one of those cases where it would be highly
> non-trivial and inefficient to put all of the checks in APR, simply due
> to the real-world nature of the bugs, but that at the same time there is
> a clear benefit available to those willing to take the time to read the
> manual and decide for themselves if it will work in their situation.
For those OSes that have a large number of cases where sendfile() doesn't
work, then we can disable sendfile() rather than checking for these cases.
However, your position mandates that the admins must do a lot of legwork to
understand if their OS has issues or not. It's not always obvious what the
corner cases are here: I'm in favor of placing that work in APR - where there
are people willing to produce appropriate patches to relax the restrictions on
that OS.
One fstatfs call will allow us to detect the FS issues we've seen: either
blacklist or whitelist fstypes per OS, I don't much care. And, we can check
for IPv6 sockets on Linux. Ideally, we'd have some way of minimizing the need
for fstatfs calls, but even without a cache of some sort (I don't know how
slow or fast fstatfs tends to be), that's a fair price to pay for correctness
and a viable attempt to maintain zero-copy performance.
Yet, I believe most of these are outright OS or driver bugs that will, over
the long run, be fixed upstream. If your OS or driver maintainers don't fix
problems with their software, then you have other issues. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 09:00:59AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> >In my experience, more users are brain-dead than OS's ;) Surely it's the
> >users who don't have a hope of diagnosing the kinds of intermittent
> >problems
> >that using sendfile can trigger who should be kept in mind?
> >
> >Users whose performance requirements are such that they will benefit
> >from the use of Sendfile will find it, it's not like the option would
> >dissapear. Even more so if it left on in the high performance config.
>
> The issue is that the APR developers can assist in this by using our
> knowledge of when it is safe to use sendfile() or not. We should not be
> tasking administrators with this responsibility.
I disagree. I think the reality of the bugs we are dealing with tasks
administrators with this responsibility. Whether or not an administrator
chooses to host their content on a network mount for example - is
clearly an administrative decision, and it's not so easily detectable by
APR.
Your own arguments are that people who can benefit from the power of
sendfile should be able to. An admin on Linux who uses ext2/3 should be
able to, so having a niaive "if (linux) no_sendfile" is far too
unwieldly, and the logic for testing support filesystems and so on would
be pretty exhaustive and might even hamper any benefits of using
sendfile in the first place.
> I abhor knobs that have
> to be turned on in order for the system to work to the best of its ability.
Default values are never about working a system to the best of its
ability. Surely, they are about working correctly and reliably. Any
number of changes can be made to a httpd conf to speed things up, and
they are always going to require the knowledge of the system
administrator. How is this any different?
> It's bad behavior on our part: we shouldn't need a 'high performance
> config'. If we do, then it means that the portability layer failed.
It's all about trade-offs. Turning off overrides means no stats for
.htaccess, that's a performance increase in one sense, but it's a
feature-loss in another. Turning on Mmap can boost throughput, but make
you use more memory or reduce reliability with multiple CPU's or
network shares - who decides which is better performance? Having more
children means you can handle more clients more quickly, but it might
increase the load on your machine - who decides which is a performance
increase?
Enabling Sendfile might get you better throughput, with less CPU/Memory
usage, but then again it might mean you serve files less reliably. Who
decides if this is a performance increase?
> Therefore, we can make it such that the httpd's default configuration does
> the right thing a heck of a lot more often than it does now. And, if that
> means we disable sendfile() across the board on more platforms - so be it.
I think that runs contra to your own logic about wanting people who
should be be able to benefit from it to do so.
I think it's just one of those cases where it would be highly
non-trivial and inefficient to put all of the checks in APR, simply due
to the real-world nature of the bugs, but that at the same time there is
a clear benefit available to those willing to take the time to read the
manual and decide for themselves if it will work in their situation.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 09:00:59AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
> >In my experience, more users are brain-dead than OS's ;) Surely it's the
> >users who don't have a hope of diagnosing the kinds of intermittent
> >problems
> >that using sendfile can trigger who should be kept in mind?
> >
> >Users whose performance requirements are such that they will benefit
> >from the use of Sendfile will find it, it's not like the option would
> >dissapear. Even more so if it left on in the high performance config.
>
> The issue is that the APR developers can assist in this by using our
> knowledge of when it is safe to use sendfile() or not. We should not be
> tasking administrators with this responsibility.
I disagree. I think the reality of the bugs we are dealing with tasks
administrators with this responsibility. Whether or not an administrator
chooses to host their content on a network mount for example - is
clearly an administrative decision, and it's not so easily detectable by
APR.
Your own arguments are that people who can benefit from the power of
sendfile should be able to. An admin on Linux who uses ext2/3 should be
able to, so having a niaive "if (linux) no_sendfile" is far too
unwieldly, and the logic for testing support filesystems and so on would
be pretty exhaustive and might even hamper any benefits of using
sendfile in the first place.
> I abhor knobs that have
> to be turned on in order for the system to work to the best of its ability.
Default values are never about working a system to the best of its
ability. Surely, they are about working correctly and reliably. Any
number of changes can be made to a httpd conf to speed things up, and
they are always going to require the knowledge of the system
administrator. How is this any different?
> It's bad behavior on our part: we shouldn't need a 'high performance
> config'. If we do, then it means that the portability layer failed.
It's all about trade-offs. Turning off overrides means no stats for
.htaccess, that's a performance increase in one sense, but it's a
feature-loss in another. Turning on Mmap can boost throughput, but make
you use more memory or reduce reliability with multiple CPU's or
network shares - who decides which is better performance? Having more
children means you can handle more clients more quickly, but it might
increase the load on your machine - who decides which is a performance
increase?
Enabling Sendfile might get you better throughput, with less CPU/Memory
usage, but then again it might mean you serve files less reliably. Who
decides if this is a performance increase?
> Therefore, we can make it such that the httpd's default configuration does
> the right thing a heck of a lot more often than it does now. And, if that
> means we disable sendfile() across the board on more platforms - so be it.
I think that runs contra to your own logic about wanting people who
should be be able to benefit from it to do so.
I think it's just one of those cases where it would be highly
non-trivial and inefficient to put all of the checks in APR, simply due
to the real-world nature of the bugs, but that at the same time there is
a clear benefit available to those willing to take the time to read the
manual and decide for themselves if it will work in their situation.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> In my experience, more users are brain-dead than OS's ;) Surely it's the
> users who don't have a hope of diagnosing the kinds of intermittent problems
> that using sendfile can trigger who should be kept in mind?
>
> Users whose performance requirements are such that they will benefit
> from the use of Sendfile will find it, it's not like the option would
> dissapear. Even more so if it left on in the high performance config.
The issue is that the APR developers can assist in this by using our knowledge
of when it is safe to use sendfile() or not. We should not be tasking
administrators with this responsibility. I abhor knobs that have to be turned
on in order for the system to work to the best of its ability. It's bad
behavior on our part: we shouldn't need a 'high performance config'. If we
do, then it means that the portability layer failed.
Therefore, we can make it such that the httpd's default configuration does the
right thing a heck of a lot more often than it does now. And, if that means
we disable sendfile() across the board on more platforms - so be it. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> In my experience, more users are brain-dead than OS's ;) Surely it's the
> users who don't have a hope of diagnosing the kinds of intermittent problems
> that using sendfile can trigger who should be kept in mind?
>
> Users whose performance requirements are such that they will benefit
> from the use of Sendfile will find it, it's not like the option would
> dissapear. Even more so if it left on in the high performance config.
The issue is that the APR developers can assist in this by using our knowledge
of when it is safe to use sendfile() or not. We should not be tasking
administrators with this responsibility. I abhor knobs that have to be turned
on in order for the system to work to the best of its ability. It's bad
behavior on our part: we shouldn't need a 'high performance config'. If we
do, then it means that the portability layer failed.
Therefore, we can make it such that the httpd's default configuration does the
right thing a heck of a lot more often than it does now. And, if that means
we disable sendfile() across the board on more platforms - so be it. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 08:23:18AM -0800, Justin Erenkrantz wrote:
> I absolutely refuse to punish users who are using good OSes because some
> OSes are brain-dead.
In my experience, more users are brain-dead than OS's ;) Surely it's the
users who don't have a hope of diagnosing the kinds of intermittent problems
that using sendfile can trigger who should be kept in mind?
Users whose performance requirements are such that they will benefit
from the use of Sendfile will find it, it's not like the option would
dissapear. Even more so if it left on in the high performance config.
> Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
> don't care. However, blocking sendfile on non-buggy OSes is not a solution
> that I am willing to sign off on.
It's not like anyone is proposing that the option dissapear!
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf
files?
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 11:23 AM 3/18/2005, Justin Erenkrantz wrote:
>I absolutely refuse to punish users who are using good OSes because
>some OSes are brain-dead. This is exactly the role that APR is
>meant to fill
>
>Feel free to advocate Linux always returning APR_ENOTIMPL for
>sendfile - I don't care. However, blocking sendfile on non-buggy
>OSes is not a solution that I am willing to sign off on. -- justin
Isn't this about a change to not enable sendfile in the default HTTPd
config, not a change to APR to disable sendfile? In that case, this
won't affect existing HTTPd users, because they already have it
enabled in their config, and the default config never replaces an
existing config.
Re: do we still want sendfile enabled with our default conf files?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Mar 18, 2005 at 08:23:18AM -0800, Justin Erenkrantz wrote:
> I absolutely refuse to punish users who are using good OSes because some
> OSes are brain-dead.
In my experience, more users are brain-dead than OS's ;) Surely it's the
users who don't have a hope of diagnosing the kinds of intermittent problems
that using sendfile can trigger who should be kept in mind?
Users whose performance requirements are such that they will benefit
from the use of Sendfile will find it, it's not like the option would
dissapear. Even more so if it left on in the high performance config.
> Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
> don't care. However, blocking sendfile on non-buggy OSes is not a solution
> that I am willing to sign off on.
It's not like anyone is proposing that the option dissapear!
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: do we still want sendfile enabled with our default conf files?
Posted by Ryan Bloom <rb...@gmail.com>.
I didn't dig into the problems that I was seeing on Linux, but I know
that it was IPv4. I don't know the filesystem, but I can find out. I
assumed it was the mutli-threaded aspect that was causing the trouble,
but that was really just a guess.
Ryan
On Fri, 18 Mar 2005 09:00:26 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
>
> > That's fine. Pay attention to what I suggested. Default to
> > non-native sendfile, until we have know that it works. If you have an
> > OS that you know for a fact does sendfile correctly, then that would
> > be a case where we know that it works.
>
> I tend to prefer Jeff's solution of having APR return APR_ENOTIMPL when the
> APR_SENDFILE_AUTODETECT flag is set and we'd fail. I'm ambivalent if we
> decide to have apr_socket_sendfile() internally call emulate_sendfile because
> apr_socket_sendfile() has always been an optional function (APR_HAS_SENDFILE).
> If we go this route of having it mask the choice, then apr_socket_sendfile()
> should always be present and we can clean up the code in httpd accordingly.
>
> I also think that we likely already know the cases when sendfile is going to
> succeed on a particular platform. I haven't heard any claims that sendfile()
> fails on Linux when using only IPv4 and ext{23}. So, yes, I think we can do
> better than a straight APR_ENOTIMPL - but if people don't want to write the
> checks, then we'll just live with writev() on that platform. -- justin
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: do we still want sendfile enabled with our default conf
files?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:03 AM 3/18/2005, Jim Jagielski wrote:
>Seems to me, having apr_socket_sendfile universally available and
>having APR deal with whether sendfile exists or how to
>implement or emulate it makes the most sense...
The corollary is that if apr_socket_sendfile doesn't do what
the user expects, they may have a better approach than we do
in fake_sendfile.
The single biggest sendfile() problem is remotely mounted
filesystems, which (AFAIK) most platforms don't successfully
support. Does apr know this, can we determine this (in a
relatively optimial manner) or is it easer for our user to
determine it at a specific time (such as when httpd is going
to do a stat() anyways?)
I'm a little worried that fake_sendfile is less optimal than
other games which can be played in multi-connection server
cores, possibly future mpm designs.
Bill
Re: do we still want sendfile enabled with our default conf
files?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:03 AM 3/18/2005, Jim Jagielski wrote:
>Seems to me, having apr_socket_sendfile universally available and
>having APR deal with whether sendfile exists or how to
>implement or emulate it makes the most sense...
The corollary is that if apr_socket_sendfile doesn't do what
the user expects, they may have a better approach than we do
in fake_sendfile.
The single biggest sendfile() problem is remotely mounted
filesystems, which (AFAIK) most platforms don't successfully
support. Does apr know this, can we determine this (in a
relatively optimial manner) or is it easer for our user to
determine it at a specific time (such as when httpd is going
to do a stat() anyways?)
I'm a little worried that fake_sendfile is less optimal than
other games which can be played in multi-connection server
cores, possibly future mpm designs.
Bill
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
> That's fine. Pay attention to what I suggested. Default to
> non-native sendfile, until we have know that it works. If you have an
> OS that you know for a fact does sendfile correctly, then that would
> be a case where we know that it works.
I tend to prefer Jeff's solution of having APR return APR_ENOTIMPL when the
APR_SENDFILE_AUTODETECT flag is set and we'd fail. I'm ambivalent if we
decide to have apr_socket_sendfile() internally call emulate_sendfile because
apr_socket_sendfile() has always been an optional function (APR_HAS_SENDFILE).
If we go this route of having it mask the choice, then apr_socket_sendfile()
should always be present and we can clean up the code in httpd accordingly.
I also think that we likely already know the cases when sendfile is going to
succeed on a particular platform. I haven't heard any claims that sendfile()
fails on Linux when using only IPv4 and ext{23}. So, yes, I think we can do
better than a straight APR_ENOTIMPL - but if people don't want to write the
checks, then we'll just live with writev() on that platform. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
> That's fine. Pay attention to what I suggested. Default to
> non-native sendfile, until we have know that it works. If you have an
> OS that you know for a fact does sendfile correctly, then that would
> be a case where we know that it works.
I tend to prefer Jeff's solution of having APR return APR_ENOTIMPL when the
APR_SENDFILE_AUTODETECT flag is set and we'd fail. I'm ambivalent if we
decide to have apr_socket_sendfile() internally call emulate_sendfile because
apr_socket_sendfile() has always been an optional function (APR_HAS_SENDFILE).
If we go this route of having it mask the choice, then apr_socket_sendfile()
should always be present and we can clean up the code in httpd accordingly.
I also think that we likely already know the cases when sendfile is going to
succeed on a particular platform. I haven't heard any claims that sendfile()
fails on Linux when using only IPv4 and ext{23}. So, yes, I think we can do
better than a straight APR_ENOTIMPL - but if people don't want to write the
checks, then we'll just live with writev() on that platform. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Ryan Bloom <rb...@gmail.com>.
That's fine. Pay attention to what I suggested. Default to
non-native sendfile, until we have know that it works. If you have an
OS that you know for a fact does sendfile correctly, then that would
be a case where we know that it works.
Instead of
#ifndef LINUX|WIN32|AIX|HPUX
sendfile(....)
#else
fake_sendfile(....)
#endif
do:
#ifdef SomeOSThatWorks
sendfile(.....)
#else
fake_sendfile(....)
#endif
Since the beginning of APR, we thought that we knew how to get
sendfile working on most of our supported OS'. That's why we included
sendfile support. It turns out though, that for many of those
platforms, sendfile just doesn't work in some situations. When we
have a platform without the bugs, then yes we should use sendfile, but
for all other cases I care infinately more about correctness than
speed.
Ryan
On Fri, 18 Mar 2005 08:23:18 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
>
> > funny, I took the list of exceptions to be so large and hard to
> > maintain that it made more sense to go with Jeff's original idea of
> > just disabling sendfile by default unless a user specifically decided
> > to enable it. I just had to debug a problem for a friend with
> > sendfile on Linux. I don't know what caused the problem, but
> > disabling sendfile solved it immediately. Seems to me that until our
> > sendfile support is better, we should err on the side of always
> > sending the data correctly instead of absolutely as fast as possible.
>
> I absolutely refuse to punish users who are using good OSes because some OSes
> are brain-dead. This is exactly the role that APR is meant to fill: if we
> know of conditions where it is unsafe to use sendfile, we won't use it unless
> explicitly told so by the user.
>
> The minimal check can be:
>
> if (flags & APR_SENDFILE_CHECK) {
> #ifdef LINUX || WIN32 || AIX || HPUX
> return APR_ENOTIMPL;
> #endif
> }
>
> As people determine what conditions sendfile is safe (or causes problems),
> then we can add those.
>
> Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
> don't care. However, blocking sendfile on non-buggy OSes is not a solution
> that I am willing to sign off on. -- justin
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: do we still want sendfile enabled with our default conf files?
Posted by Ryan Bloom <rb...@gmail.com>.
That's fine. Pay attention to what I suggested. Default to
non-native sendfile, until we have know that it works. If you have an
OS that you know for a fact does sendfile correctly, then that would
be a case where we know that it works.
Instead of
#ifndef LINUX|WIN32|AIX|HPUX
sendfile(....)
#else
fake_sendfile(....)
#endif
do:
#ifdef SomeOSThatWorks
sendfile(.....)
#else
fake_sendfile(....)
#endif
Since the beginning of APR, we thought that we knew how to get
sendfile working on most of our supported OS'. That's why we included
sendfile support. It turns out though, that for many of those
platforms, sendfile just doesn't work in some situations. When we
have a platform without the bugs, then yes we should use sendfile, but
for all other cases I care infinately more about correctness than
speed.
Ryan
On Fri, 18 Mar 2005 08:23:18 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
>
> > funny, I took the list of exceptions to be so large and hard to
> > maintain that it made more sense to go with Jeff's original idea of
> > just disabling sendfile by default unless a user specifically decided
> > to enable it. I just had to debug a problem for a friend with
> > sendfile on Linux. I don't know what caused the problem, but
> > disabling sendfile solved it immediately. Seems to me that until our
> > sendfile support is better, we should err on the side of always
> > sending the data correctly instead of absolutely as fast as possible.
>
> I absolutely refuse to punish users who are using good OSes because some OSes
> are brain-dead. This is exactly the role that APR is meant to fill: if we
> know of conditions where it is unsafe to use sendfile, we won't use it unless
> explicitly told so by the user.
>
> The minimal check can be:
>
> if (flags & APR_SENDFILE_CHECK) {
> #ifdef LINUX || WIN32 || AIX || HPUX
> return APR_ENOTIMPL;
> #endif
> }
>
> As people determine what conditions sendfile is safe (or causes problems),
> then we can add those.
>
> Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
> don't care. However, blocking sendfile on non-buggy OSes is not a solution
> that I am willing to sign off on. -- justin
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:51 AM -0500 Jeff Trawick <tr...@gmail.com>
wrote:
> ouch, add one more brain-dead OS to the list: FreeBSD; some levels
> have had filesystems which don't handle sendfile correctly (same type
> of issue which hits some Linux users)
Do you have details? FreeBSD's sendfile was broken for some versions (i.e.
<4.10 with threading). We already have configure checks in APR for some of
this.
I find it amusing that Linux-centric developers feel special in that they
should disable things across the board because their OS has a bug while the
FreeBSD-using developers just add in checks to isolate the issue on their
platform. =) -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 18 Mar 2005 08:23:18 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
>
> > funny, I took the list of exceptions to be so large and hard to
> > maintain that it made more sense to go with Jeff's original idea of
> > just disabling sendfile by default unless a user specifically decided
> > to enable it. I just had to debug a problem for a friend with
> > sendfile on Linux. I don't know what caused the problem, but
> > disabling sendfile solved it immediately. Seems to me that until our
> > sendfile support is better, we should err on the side of always
> > sending the data correctly instead of absolutely as fast as possible.
>
> I absolutely refuse to punish users who are using good OSes because some OSes
> are brain-dead.
ouch, add one more brain-dead OS to the list: FreeBSD; some levels
have had filesystems which don't handle sendfile correctly (same type
of issue which hits some Linux users)
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
> funny, I took the list of exceptions to be so large and hard to
> maintain that it made more sense to go with Jeff's original idea of
> just disabling sendfile by default unless a user specifically decided
> to enable it. I just had to debug a problem for a friend with
> sendfile on Linux. I don't know what caused the problem, but
> disabling sendfile solved it immediately. Seems to me that until our
> sendfile support is better, we should err on the side of always
> sending the data correctly instead of absolutely as fast as possible.
I absolutely refuse to punish users who are using good OSes because some OSes
are brain-dead. This is exactly the role that APR is meant to fill: if we
know of conditions where it is unsafe to use sendfile, we won't use it unless
explicitly told so by the user.
The minimal check can be:
if (flags & APR_SENDFILE_CHECK) {
#ifdef LINUX || WIN32 || AIX || HPUX
return APR_ENOTIMPL;
#endif
}
As people determine what conditions sendfile is safe (or causes problems),
then we can add those.
Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
don't care. However, blocking sendfile on non-buggy OSes is not a solution
that I am willing to sign off on. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rb...@gmail.com> wrote:
> funny, I took the list of exceptions to be so large and hard to
> maintain that it made more sense to go with Jeff's original idea of
> just disabling sendfile by default unless a user specifically decided
> to enable it. I just had to debug a problem for a friend with
> sendfile on Linux. I don't know what caused the problem, but
> disabling sendfile solved it immediately. Seems to me that until our
> sendfile support is better, we should err on the side of always
> sending the data correctly instead of absolutely as fast as possible.
I absolutely refuse to punish users who are using good OSes because some OSes
are brain-dead. This is exactly the role that APR is meant to fill: if we
know of conditions where it is unsafe to use sendfile, we won't use it unless
explicitly told so by the user.
The minimal check can be:
if (flags & APR_SENDFILE_CHECK) {
#ifdef LINUX || WIN32 || AIX || HPUX
return APR_ENOTIMPL;
#endif
}
As people determine what conditions sendfile is safe (or causes problems),
then we can add those.
Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
don't care. However, blocking sendfile on non-buggy OSes is not a solution
that I am willing to sign off on. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Cliff Woolley wrote:
> On Fri, 18 Mar 2005, Ryan Bloom wrote:
>
>
>>disabling sendfile solved it immediately. Seems to me that until our
>>sendfile support is better, we should err on the side of always
>>sending the data correctly instead of absolutely as fast as possible.
>>
>>I would much rather have APR default to not using the native sendfile,
>>and only enable native sendfile when we have a lot of evidence that it
>>does work correctly.
>
>
> Agreed on both points. +1
>
> --Cliff
>
+1
Bill
Re: do we still want sendfile enabled with our default conf files?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Cliff Woolley wrote:
> On Fri, 18 Mar 2005, Ryan Bloom wrote:
>
>
>>disabling sendfile solved it immediately. Seems to me that until our
>>sendfile support is better, we should err on the side of always
>>sending the data correctly instead of absolutely as fast as possible.
>>
>>I would much rather have APR default to not using the native sendfile,
>>and only enable native sendfile when we have a lot of evidence that it
>>does work correctly.
>
>
> Agreed on both points. +1
>
> --Cliff
>
+1
Bill
Re: do we still want sendfile enabled with our default conf files?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 18 Mar 2005, Ryan Bloom wrote:
> disabling sendfile solved it immediately. Seems to me that until our
> sendfile support is better, we should err on the side of always
> sending the data correctly instead of absolutely as fast as possible.
>
> I would much rather have APR default to not using the native sendfile,
> and only enable native sendfile when we have a lot of evidence that it
> does work correctly.
Agreed on both points. +1
--Cliff
Re: do we still want sendfile enabled with our default conf files?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 18 Mar 2005, Ryan Bloom wrote:
> disabling sendfile solved it immediately. Seems to me that until our
> sendfile support is better, we should err on the side of always
> sending the data correctly instead of absolutely as fast as possible.
>
> I would much rather have APR default to not using the native sendfile,
> and only enable native sendfile when we have a lot of evidence that it
> does work correctly.
Agreed on both points. +1
--Cliff
Re: do we still want sendfile enabled with our default conf files?
Posted by Ryan Bloom <rb...@gmail.com>.
funny, I took the list of exceptions to be so large and hard to
maintain that it made more sense to go with Jeff's original idea of
just disabling sendfile by default unless a user specifically decided
to enable it. I just had to debug a problem for a friend with
sendfile on Linux. I don't know what caused the problem, but
disabling sendfile solved it immediately. Seems to me that until our
sendfile support is better, we should err on the side of always
sending the data correctly instead of absolutely as fast as possible.
I would much rather have APR default to not using the native sendfile,
and only enable native sendfile when we have a lot of evidence that it
does work correctly.
Ryan
On Fri, 18 Mar 2005 08:07:01 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> > ...snip, snip...
> > 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.)
>
> Is the kernel turning incorrect on AIX by default? Will this be fixed in some
> future releases? You could do lots of things to corrupt your kernel by tuning
> in other ways - so unless this is by default, I can't see why we should block
> this.
>
> > ...snip, snip...
>
> +1 to this list of exceptions and adding a new flag called APR_SENDFILE_CHECK
> (or APR_SENDFILE_AUTODETECT) to apr_socket_sendfile. -- justin
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: do we still want sendfile enabled with our default conf files?
Posted by Ryan Bloom <rb...@gmail.com>.
funny, I took the list of exceptions to be so large and hard to
maintain that it made more sense to go with Jeff's original idea of
just disabling sendfile by default unless a user specifically decided
to enable it. I just had to debug a problem for a friend with
sendfile on Linux. I don't know what caused the problem, but
disabling sendfile solved it immediately. Seems to me that until our
sendfile support is better, we should err on the side of always
sending the data correctly instead of absolutely as fast as possible.
I would much rather have APR default to not using the native sendfile,
and only enable native sendfile when we have a lot of evidence that it
does work correctly.
Ryan
On Fri, 18 Mar 2005 08:07:01 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> > ...snip, snip...
> > 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.)
>
> Is the kernel turning incorrect on AIX by default? Will this be fixed in some
> future releases? You could do lots of things to corrupt your kernel by tuning
> in other ways - so unless this is by default, I can't see why we should block
> this.
>
> > ...snip, snip...
>
> +1 to this list of exceptions and adding a new flag called APR_SENDFILE_CHECK
> (or APR_SENDFILE_AUTODETECT) to apr_socket_sendfile. -- justin
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: do we still want sendfile enabled with our default conf files?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 18 Mar 2005 09:05:37 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:53 AM -0500 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> > there are fixes available for the default tuning;
>
> So, will we be able to isolate down to a revision of AIX that has these fixes?
Sure, but the bogometer would break when held anywhere near the code ;)
> > I have no
> > information on whether or not users have shot themselves in the foot
> > in addition to getting bitten by the default tuning
>
> I have little sympathy for users who custom tune their kernel and see
> something bust because of that. I'm not going to lose sleep over that. --
sympathy seems to be the operative word here... perhaps there is a
happy medium somewhere between showing sympathy for the
can't-help-themselves-so-stupid-they-picked-a-broken-OS folks and
showing sympathy for the
running-their-system-at-98%-CPU-serving-static-files-and-need-some-headroom
folks...
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 11:53 AM -0500 Jeff Trawick <tr...@gmail.com>
wrote:
> there are fixes available for the default tuning;
So, will we be able to isolate down to a revision of AIX that has these fixes?
> I have no
> information on whether or not users have shot themselves in the foot
> in addition to getting bitten by the default tuning
I have little sympathy for users who custom tune their kernel and see
something bust because of that. I'm not going to lose sleep over that. --
justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 18 Mar 2005 08:07:01 -0800, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> > ...snip, snip...
> > 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.)
>
> Is the kernel turning incorrect on AIX by default? Will this be fixed in some
> future releases?
there are fixes available for the default tuning; I have no
information on whether or not users have shot themselves in the foot
in addition to getting bitten by the default tuning
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <tr...@gmail.com>
wrote:
> ...snip, snip...
> 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.)
Is the kernel turning incorrect on AIX by default? Will this be fixed in some
future releases? You could do lots of things to corrupt your kernel by tuning
in other ways - so unless this is by default, I can't see why we should block
this.
> ...snip, snip...
+1 to this list of exceptions and adding a new flag called APR_SENDFILE_CHECK
(or APR_SENDFILE_AUTODETECT) to apr_socket_sendfile. -- justin
Re: do we still want sendfile enabled with our default conf files?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <tr...@gmail.com>
wrote:
> ...snip, snip...
> 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.)
Is the kernel turning incorrect on AIX by default? Will this be fixed in some
future releases? You could do lots of things to corrupt your kernel by tuning
in other ways - so unless this is by default, I can't see why we should block
this.
> ...snip, snip...
+1 to this list of exceptions and adding a new flag called APR_SENDFILE_CHECK
(or APR_SENDFILE_AUTODETECT) to apr_socket_sendfile. -- justin