Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of chip@force-elite.com
 designates 72.232.80.58 as permitted sender)
Message-ID: <453E47F2.6010905@force-elite.com>
Date: Tue, 24 Oct 2006 10:05:54 -0700
From: Paul Querna <chip@force-elite.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: mod_disk_cache in trunk, was Re: mod_disk_cache summarization
References: <453D1694.1010203@turner.com> <453D220E.3000706@sharp.fm>
    <453D2508.5060902@haxent.com.br> <453D2766.5090108@sharp.fm>
    <453DC13A.10105@force-elite.com>
 <56966.196.8.104.27.1161678044.squirrel@www.sharp.fm>
In-Reply-To: <56966.196.8.104.27.1161678044.squirrel@www.sharp.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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