Re: [tlug] Re: Apache: Logging: how-to pipe logs orlogtoanothermachine (was Disk

[Bruno Raoult <br@example.com>]

On Mon, 2002-09-09 at 03:22, Viktor Pavlenko wrote:
>     BR> strace on gzip gives:
>     BR> [...]
>     BR> read(0, "VIDIA NVdriver Kernel Module  1."..., 8192) = 8192
>     BR> read(0, "(li) CMD (cd /www/li-bridge; wge"..., 32768) = 8192
>     BR> read(0, "] Rejected at IN(default) filter"..., 24576) = 8192
>     BR> write(1, "\266\255\334\221\322\\\333\272$)\315\267\255\272\332!I"...,
>     BR> 16384) = 16384
>     BR> [...]
> 
>     BR> This means that the input buffer is BUFSIZ, and output buffer is
>     BR> 2*BUFSIZ.
> 
> Yes but you can also see several reads before the write. It means that
> gzip writes its output after certain number of reads (6 for the first
> output, 6*BUFSIZ = 49152 according to what I found out). But I think
> the internal buffering (a number of reads followed by a number of
> writes) depends on the compressing algorithm.
> 
> Viktor

I don't think so: As soon as 16K are ready for output, they are written.
You could have 2, 4, 10, or 100 8K reads prior to this, depending on
your input file (see your file filled with "1", where gzip will read all
the data before the unique output...).
I just checked gzip source files (gzip.h), and they don't use stdio
(this was obvious because of the different output buffer size), but
rather use they own buffers. These buffers sizes are different on input
and output, and are decided at compilation time: 8K or 32K for input, 8K
or 16K for output.
*BUT* you could also force these values at compilation time (they are
not overwritten), meaning that your OUTBUFSIZE could be different...

br.
 
-- 
GPG Key: 653514E5 (http://www.raoult.com/gpg)
--
"When you open your Windows you'll see a light blue sky filled with
clouds.
If you look past the clouds, you'll only see the Sun."

Attachment: signature.asc
Description: This is a digitally signed message part