Re: [squid-users] cache_dir (dirty) question

From: Michel \(M\) <michel@dont-contact.us>
Date: Tue, 6 May 2008 11:03:07 -0300 (BRT)

Henrik Nordstrom disse na ultima mensagem:
> On tis, 2008-05-06 at 06:45 -0300, Michel (M) wrote:
>
>> lets say the swap.state is corrupt for any reason I can delete it and
>> squid should rebuild it correctly right?
>
> Yes, but some information is lost when doing so, and it will take a very
> very long time if your cache is large.
>
>
>> so since squid does this swap.state -> swap.state.new -> swap.state
>> thing
>> anyway I could change my startup script to delete any swap.state before
>> starting squid to make sure it is coming up clean, or am I wrong here?
>
> Partially wrong.
>
> There is information in swap.state that can not be rebuilt from the
> cache directory. Mainly freshness updates and access counters.
>
> The rewrite of swap.state on startup/rotate is to compact the file
> pruning out no longer relevant details. While running swap.state is used
> as a journal for the cache.
>
> If swap.state is lost Squid will attempt to rebuild the cache index from
> the individual files, but not all information is available in the
> individual files and additionally it's a very I/O intensive task as each
> file has to be opened and read..
>

thank you very much for this clarification

I guess the counters are updated soon a file got hit again or not? So
worse case is it is being fetched again or not checked and served from
cache right?

since my hardware is fast and zfs is helping here a lot, I lose only 5-10
minutes in comparism to a normal clean rebuild with -F flag, seems better
than discovering hours later that something went wrong, so since there is
the swap.state problem I related already it seems to be a valid work
around for me at this moment to get me out of service outage.

thank's
michel

...

****************************************************
Tecnologia Internet Matik http://info.matik.com.br
Sistemas Wireless para o Provedor Banda Larga
Hospedagem e Email personalizado - e claro, no Brasil.
****************************************************
Received on Tue May 06 2008 - 14:03:33 MDT

This archive was generated by hypermail 2.2.0 : Tue May 13 2008 - 12:00:02 MDT