You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Niklas Edmundsson <ni...@acc.umu.se> on 2006/09/14 11:17:50 UTC
[PATCH] (resend) mod_disk_cache LFS-aware config
To facilitate the merging of our large mod_disk_cache fixup I will
send small patches that fix various bugs so that they can be applied
incrementally to trunk with relevant discussion limited to those
patches and me not having to respin entire patchsets due to trivial
fixes to patches like this one.
If you want larger patchsets instead of this "baby steps" approach
that's fine by me, but small pieces usually allows for easier review
when merging.
This patch and the jumbo patch with all fixes are also attached to bug
#39380.
This patch makes it possible to configure mod_disk_cache to cache
files that are larger than the LFS limit. While at it, I implemented
error handling so it doesn't accept things like "CacheMinFileSize
barf" anymore.
Actual LFS support (current code eats all address-space/memory in
32bit boxes) will come in a separate patch once this is commited.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
"Ensign. How do I get to Ten-Forward?" - Picard
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [PATCH] (resend) mod_disk_cache LFS-aware config
Posted by Issac Goldstand <ma...@beamartyr.net>.
A separate branch *would* really be nice; as I've got my own changes to
mod_cache that I'm working on (support for "offline-browsing" caching,
if upstream servers aren't available + attempt to cache other normally
non-cachable content (POSTs, etc)). Regardless of whether it's fit to
be included in the normal distribution, it will save a lot of headache
in making sure I'm up-to-date with the rest of the development going on...
Niklas Edmundsson wrote:
> On Thu, 14 Sep 2006, Graham Leggett wrote:
>
>> On Thu, September 14, 2006 11:17 am, Niklas Edmundsson wrote:
>>
>>> To facilitate the merging of our large mod_disk_cache fixup I will
>>> send small patches that fix various bugs so that they can be applied
>>> incrementally to trunk with relevant discussion limited to those
>>> patches and me not having to respin entire patchsets due to trivial
>>> fixes to patches like this one.
>>
>> +1.
>>
>> This also makes it easier when more than one person is working on
>> patchsets to integrate both patches.
>
> Yup. The situation seems to be complicated somewhat by Davi working on
> the cache-thingies, and doing more than just poking around in the
> mod_cache infrastructure...
>
> However, it seems that we really should start merging stuff in a tree,
> be it trunk or cache-dev or whatever, before we are sitting on two
> hard-to-merge trees which both holds significant improvements.
>
> As said, our stuff is stable in production (except for one bug that I
> suspect is an apache/apr bug, more about that when/if we get to that
> part) and transforms mod_disk_cache from unusable for us to performing
> nicely with approx 90% cache hit rate when serving ftp.acc.umu.se,
> ftp.gnome.org, se.releases/archive.ubuntu.com, releases.mozilla.org,
> ftp.se.debian.org ...
>
> /Nikke
Re: [PATCH] (resend) mod_disk_cache LFS-aware config
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 14 Sep 2006, Graham Leggett wrote:
> On Thu, September 14, 2006 2:41 pm, Niklas Edmundsson wrote:
>
>> Yup. The situation seems to be complicated somewhat by Davi working on
>> the cache-thingies, and doing more than just poking around in the
>> mod_cache infrastructure...
>>
>> However, it seems that we really should start merging stuff in a tree,
>> be it trunk or cache-dev or whatever, before we are sitting on two
>> hard-to-merge trees which both holds significant improvements.
>
> Small patches are easy to merge, easy to review, and unlikely to clash -
> what I am keen to do is start finding all the small fixes in both your and
> Davi's code, and see them all applied. Davi's patches are already
> reasonably small - is it possible to break up your patch into discrete
> bits as well?
That's my intention. I had hoped for my small patches to be applied to
trunk one by one as they come, fixing eventual objections patch by
patch instead of having to respin large patchsets that depends on
eachother. At least for the small obvious fixes this should be doable.
Ie, make small patch, submit for review/commit, fix/redo if needed. On
to next patch.
When there are more complex changes I'll probably have to do
multi-part patchsets, but I really want to avoid them since they're a
pain when it comes to rejections.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
Read the docs. Wow, what a radical concept!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [PATCH] (resend) mod_disk_cache LFS-aware config
Posted by Graham Leggett <mi...@sharp.fm>.
On Thu, September 14, 2006 2:41 pm, Niklas Edmundsson wrote:
> Yup. The situation seems to be complicated somewhat by Davi working on
> the cache-thingies, and doing more than just poking around in the
> mod_cache infrastructure...
>
> However, it seems that we really should start merging stuff in a tree,
> be it trunk or cache-dev or whatever, before we are sitting on two
> hard-to-merge trees which both holds significant improvements.
Small patches are easy to merge, easy to review, and unlikely to clash -
what I am keen to do is start finding all the small fixes in both your and
Davi's code, and see them all applied. Davi's patches are already
reasonably small - is it possible to break up your patch into discrete
bits as well?
Regards,
Graham
--
Re: [PATCH] (resend) mod_disk_cache LFS-aware config
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 14 Sep 2006, Graham Leggett wrote:
> On Thu, September 14, 2006 11:17 am, Niklas Edmundsson wrote:
>
>> To facilitate the merging of our large mod_disk_cache fixup I will
>> send small patches that fix various bugs so that they can be applied
>> incrementally to trunk with relevant discussion limited to those
>> patches and me not having to respin entire patchsets due to trivial
>> fixes to patches like this one.
>
> +1.
>
> This also makes it easier when more than one person is working on
> patchsets to integrate both patches.
Yup. The situation seems to be complicated somewhat by Davi working on
the cache-thingies, and doing more than just poking around in the
mod_cache infrastructure...
However, it seems that we really should start merging stuff in a tree,
be it trunk or cache-dev or whatever, before we are sitting on two
hard-to-merge trees which both holds significant improvements.
As said, our stuff is stable in production (except for one bug that I
suspect is an apache/apr bug, more about that when/if we get to that
part) and transforms mod_disk_cache from unusable for us to performing
nicely with approx 90% cache hit rate when serving ftp.acc.umu.se,
ftp.gnome.org, se.releases/archive.ubuntu.com, releases.mozilla.org,
ftp.se.debian.org ...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
"You have learned much, young one." - Vader
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [PATCH] (resend) mod_disk_cache LFS-aware config
Posted by Graham Leggett <mi...@sharp.fm>.
On Thu, September 14, 2006 11:17 am, Niklas Edmundsson wrote:
> To facilitate the merging of our large mod_disk_cache fixup I will
> send small patches that fix various bugs so that they can be applied
> incrementally to trunk with relevant discussion limited to those
> patches and me not having to respin entire patchsets due to trivial
> fixes to patches like this one.
+1.
This also makes it easier when more than one person is working on
patchsets to integrate both patches.
Regards,
Graham
--