httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
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:
> http://svn.apache.org/viewvc?view=rev&revision=450105
>
> 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.

Regards,
Graham
--



Mime
View raw message