httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <dirk.vangu...@jrc.it>
Subject Re: [PATCH] Proxy Garbage Collection fixes
Date Thu, 28 May 1998 12:36:16 GMT

Martin,

Looks wonderfull, especially the improved calculation method. I am just 
wondering how common the blksize() macro is to get the values out of the
inode/fs struct.

But.. should this patch clean against 1.x.. 3 ?

Dw

On Thu, 28 May 1998, Martin Kraemer wrote:

> This patch was triggered by a discussion last fall (on this list) about
> forking off the garbage collection process of the proxy module.
> Dirk-Willem van Gulik proposed a patch, and Dean replied...:
> 
> -> Subject: Re: fundamentally wrong forking prior to garbage collection in proxy/
> -> In-Reply-To: <Pine.GSO.3.96.971126165553.6555c-100000@elect6.jrc.it>
> -> Message-ID: <Pine.LNX.3.95dg3.971127110817.20694B-100000@twinlark.arctic.org>
> ->
> -> I haven't looked to see... but you should fork() twice to disassociate
> -> yourself from the child, and the child should wait for the first fork()ed
> -> process to return before continuing (otherwise there'll be a zombie).  The
> -> whole thing should be inside a block_alarms() and unblock_alarms()
> -> section.  And it's probably not something we can do under win32...
> ->
> -> You may even want to setpgrp() after the second fork so that the httpd
> -> parent can't send you SIGHUP/USR1/TERM.
> ->
> -> Dean
> ->
> -> On Wed, 26 Nov 1997, Dirk-Willem van Gulik wrote:
> -> > Forking off the garbage collecting child in the proxy.
> -> >
> -> > Anything fundamentally wrong with this quick and dirty hack, it
> -> > does seem to work and my my employer happy. But it seems to
> -> > crude to me.
> 
> This patch addresses these topics.
> 
> Furthermore, it contains the following fixes:
> *   "real world" operating systems usually allocate files on block
>     granularity of 512 bytes or bigger. The old algorithm did not
>     account for that, and would think 1023 files with 1 byte each would
>     take up less than 1 kB ;-)
>     The block size is currently initialized to 512 bytes, but should
>     probably be configurable. But with this fix, mod_proxy's idea of
>     disk usage is only "10% off" the OS's idea (it used to be >25% off).
> 
> *   take into account the non-zero size of directories. These were not
>     accounted for in the old code.
> 
> *   sensible variable types (size_t, off_t, time_t) where appropriate.
> 
> *   avoid use of applying abs() to time_t variables
> 
> *   build array of gc_ents, not (gc_ent *)'s
> 
> *   "poor man's generalized 61 bit arithmetic" for accumulating
>     file's cache size usage
> 
> *   At LogLevel debug, GC logs the current cache usage percentage and
>     the number of deleted files.
> 
>     Martin
> -- 
> | S I E M E N S |  <Martin.Kraemer@mch.sni.de>  |      Siemens Nixdorf
> | ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
> | N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
> 


Mime
View raw message