Re: Adding a drive under Squid 1.2

On Fri, 26 Jun 1998, W S wrote:

> Hi,
>
> I simply need to add an extra drive with Squid 1.2.b22
>
> I assume I run squid -z each time a new disk is installed and the existing
> cache is unaffected?

That's the theory! Squid will then automagically redistribute the load
across the extra drives and away you go.

I have a further question, as I have only performed this operation on
"like" - ie: identical - drives ... What are the effects of using
differing disk types on Squid's utilisation of the disks?

I mean, is it cool to combine slower drives with high performance drives?

Will Squid establish the necessary performance metrics to realise that
some drives are slower and hence prefer the faster ones, and so on?

What about the cache directory dispersion across the disks - should it
always be identical?

Ta, people ... keep that banter coming!

John.

PS> I think the approach used for 1.2.22 disks is neat, but what about the
log spool? Bearing in mind that the logs may be ESSENTIAL for purposes of
billing and metrics, and that they are a significant overhead for the
machine in terms of I/O and space (they must be fastidiously managed ...
else "cat $$$$ > /dev/null") !!!!

 Previously, I've tried a couple of strategies for housing the logs,
including:

 (1). Using a seperate disk (OK barring the extra cost and space
considerations)

 (2). Using the same RAID/stripped disk array set to house both the cache
and the log spool (very convenient, but dangerous)

It would seem that our options are now limited to (1). for v1.2.22 if we
go with seperately mounted disks. I've tried some kooky things, like
distributing the logs across the disks so that they share the space with
the cache, and then linking them back to a common directory for
ease-of-management, but that's really crappy and dangerous. Anyone got
better ideas?

J.

----------------------------------------------------
John V Cougar | Voice: 1800 065 744
Cache Manager |-----------------------------
Telstra Internet | E-Mail: cougar@telstra.net
----------------------------------------------------
Received on Thu Jun 25 1998 - 22:58:36 MDT