Re: 2.3STABLE - stability issues

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Fri, 8 Sep 2000 20:31:10 +0200

On 8 Sep 2000, at 12:04, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Andres Kroonmaa wrote:
>
> > did I say that?
> > Is there much difference if we talk about another disk or partition?
>
> If you consider recoverability after a disk has crashed, or the
> possibilities that someting unrelated causes the disk to be full then
> yes it is a big difference. If it resides in a properly dimensioned area
> where nothing else has access then the likelyhood that for a disk full
> condition is quite small.

 ;) I think you are little bit too strict on my wording here. In the light
 of diskfull recovery this difference is irrelevant.
 Although yes, disk-crash recovery would also be very interesting topic.

> > My major point was that squid should recover on its own from disk full
> > condition.
>
> Exactly, and what I meant to write on the disk space was more like this:
>
> Change Squid to monitor the disk space availability as one parameter
> when maintaining the cache content. If free disk space gets below the
> configured minimal amount then stop swapouts and start deletetion of
> objects to compensate for the fact. This could optionally even be the
> way Squid decides the cache size.
>
> And due to being tired I did not consider swap.state.clean. The
> following additions to the above is required:
>
> Writing to all the log files should be changed to ignore disk full
> conditions, with an option to not ignore the error for access.log and
> cache.log.
>
> If a write error is seen on swap.state then stop any further writes to
> that swap.state file and schedule a swap.state.clean write after
> removing some objects. No further swapouts should be made in this
> cache_dir until a swap.state.clean was done sucessfully.
>
> If a disk full condition is detected while writing swap.state.clean then
> abort the writeout and reschedule it after first removing some objects.
> If this is seen repeatedly then remove the current swap.state prior to
> write swap.state.clean to recover from the situation where it is
> swap.state which has filled the drive.

 Thats just what I was talking about ;)

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri Sep 08 2000 - 12:34:14 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:36 MST