Re: scsi drive error - squid blocking - lost swap.state

Alastair Waddell wrote:

> I was unable to release squid which was blocking in a permanent state
> necessitating a physical reboot (shutdown and kill/kill -9 ineffective).
> Bummer.

Sounds like your OS got really upset about that drive.

> I unmounted and commented out (in squid.conf) the particular drive and
> restarted squid with my two remaining spindles.

> 1: How can something like this happen/is there a way I could have done
> without the reboot (servers are remote located).

Not when kill -9 is ineffective. I don't know of any OS which allows you
to umount a filesystem which is in use, and processes which can't be
killed usually has outstanding I/O operations which the kernel has lost
somehow (usually due to unexpected hardware errors).

> 2: How come my swap.state file has truncated (fsck with bad block check?
> running squid with 2/3 of it's spindles???)

Hard to tell. Anything may happen when a drive or I/O bus fails and the
OS fails to properly handle the situation.
 
> I'm particularly upset, read pissed, because I only just rebuild the
> storage in this 8.7GB drive after losing it a month ago (when my IDE/OS
> drive failed).

Is this drive in the same box?

Perhaps you should investigate the level of cooling the drive receives,
and the quality of the power supply. A heavily loaded Squid system puts
quite a load on it's drives, and many low end chassis does not provide
the needed cooling to keep the drives at decent working temperatures.
 
> Finally, do I have to delete the 6.5 GB on this drive now that the
> swap.state file is 'altered'?

No. You can remove the faulty swap.state index, and Squid will rebuild
it. How: 1. shut down Squid. 2. remove swap.state. 3. start Squid again.
Note however that you need to do this fairly quickly, or Squid will
garbage collect the "lost" files and remove them.

--
Henrik Nordstrom
Spare time Squid hacker