Ruediger Pluem wrote: > > On 09/26/2006 01:00 PM, Joe Orton wrote: >> On Tue, Sep 26, 2006 at 10:52:18AM +0200, Niklas Edmundsson wrote: >> >>> This patch depends on "mod_disk_cache LFS-aware config" submitted >>> earlier and is for trunk. >>> >>> It makes caching of large files possible on 32bit machines by: >>> >>> * Realising that a file is a file and can be copied as such, without >>> reading the whole thing into memory first. >> >> This was discussed a while back. I think this is an API problem which >> needs to be fixed at API level, not something which should be worked >> around by adding bucket-type-specific hacks. The "store_body" callback >> needs to be able to operate like a real output filter so it can avoid >> the buffering-buckets-into-memory problem; as in: >> >> while (brigade not empty) >> 1. read data from bucket >> 2. write data to disk >> 3. pass bucket up output filter chain >> 4. delete bucket > > I agree. But in the case that we want to save a file bucket, can't we use > sendfile in this case? Something like ap(r)_store_file_bucket which would > store it via sendfile or splice on Linux would be really neat. Of course > a lot more details would need to be worked out e.g. how and if this function > changes the file bucket and what happens to the position of the src and target > file pointers in the file.
Linux sendfile() only works on mmapable fds to sockets. splice() one of the two fds must refer to a pipe (afaik). tee() both fds must refer to pipes. -- Davi Arnaut
