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 --
