httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <>
Subject Re: mod_disk_cache in trunk, was Re: mod_disk_cache summarization
Date Tue, 24 Oct 2006 17:39:29 GMT
On Tue, October 24, 2006 7:05 pm, Paul Querna wrote:

> Well, yes, you are right, I finally had time to read some of the changes
> in trunk, and r450105 is freaking crazy:
> It replaced a cheap atomic operation, with copying the entire file off
> disk in chunks.  How could that ever make sense?

Previous behaviour was to load the entire bucket - all 4.7GB of it - into
RAM, and then attempted to write it to disk, which never happened because
the process had aborted at this point with an out of memory condition.

I fail to see how the previous behaviour could make sense, but there you go.

The current behaviour is also wrong, because mod_disk_cache should know
nothing about buckets whatsoever. This will be moved into an output filter
capable of writing to a file.

> The final MOVE of the temp file to the cache file should of had NOTHING
> to do with making it safe for large files.  It seems the patch (and
> CHANGES entry) did way more than what was described.

I don't see anything in that particular patch that did the removal of the
temp files. I looked at lots of patches trying to combine Davi's and
Niklas' work, so I don't remember at this point which did.

>> mod_disk_cache needs to be high performance yes, but not to the point
>> where that means it's broken on half the platforms.
> If it works on FreeBSD, Linux, and Solaris on Fridays, its good enough
> for me.

If it results in people going to the effort of rewriting what is there now
rather than using it, then it's not good enough for me.


View raw message