Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Fri, 18 Mar 2005 10:34:36 -0800
From: Justin Erenkrantz <justin@erenkrantz.com>
To: colm@stdlib.net, dev@httpd.apache.org
cc: dev@apr.apache.org
Subject: Re: do we still want sendfile enabled with our default conf files?
Message-ID: <89A562E993DB0B79130F4B3D@[10.0.1.81]>
In-Reply-To: <20050318171817.GA5562@castlerea.stdlib.net.>
References: <20050317141250.GA28555@castlerea.stdlib.net.>
 <20050317152754.GI5790@scotch.ics.uci.edu>
 <cc67648e050317160175a8a153@mail.gmail.com>
 <20050318013331.GO5790@scotch.ics.uci.edu>
 <cc67648e0503180259929bc4@mail.gmail.com>
 <CE3CD595B8676A3F6F4E5BD5@10.0.1.81>
 <1f1d98205031808126698802b@mail.gmail.com>
 <6A59038878FF133648C83BDC@[10.0.1.81]>
 <20050318163408.GA5352@castlerea.stdlib.net.>
 <91AF42FAD9551FF95D46DE21@[10.0.1.81]>
 <20050318171817.GA5562@castlerea.stdlib.net.>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Friday, March 18, 2005 5:18 PM +0000 Colm MacCarthaigh <colm@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