apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: do we still want sendfile enabled with our default conf files?
Date Fri, 18 Mar 2005 19:44:00 GMT
On Fri, Mar 18, 2005 at 10:34:36AM -0800, Justin Erenkrantz wrote:
> --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. 

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

Mime
View raw message