httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject mod_disk_cache in trunk, was Re: mod_disk_cache summarization
Date Tue, 24 Oct 2006 17:05:54 GMT
Graham Leggett wrote:
> On Tue, October 24, 2006 9:31 am, Paul Querna wrote:
> 
>>> The prerequisite is that APR needs to be taught about this scheme, and
>>> it has to work portably across all platforms.
>> No it doesn't.  mod_disk_cache makes many assumptions about the
>> underlying OS, like how moving a file on the same file system is atomic,
>> and how you can move files that have open file descriptors, both of
>> which aren't true with some file systems or operating systems (like uh..
>> windows).
> 
> As I understand, there is no more file moving inside mod_disk_cache, so
> this is no longer true.

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?

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.

>> mod_disk_cache is a high performance part, lets make it work great on
>> most unixy/POSIX type platforms, and come back to making it portable
>> later.
> 
> I'd rather not do a whole lot of work coming up with a works-for-me cache,
> and then have to field a whole lot of bug reports (like, say from Windows
> users ;) ) and then have to fix all the problems that come up by rewriting
> everything again.
> 
> 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.

-Paul

Mime
View raw message