Re: cache_dir config

From: Robert Collins <robert.collins@dont-contact.us>
Date: Fri, 2 Feb 2001 08:28:19 +1100

The modoule code I'm working on will make that plugin parser options quite easy to implement...

..

----- Original Message -----
From: "Andres Kroonmaa" <andre@online.ee>
To: "Adrian Chadd" <adrian@creative.net.au>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, February 02, 2001 7:03 AM
Subject: Re: cache_dir config

On 2 Feb 2001, at 3:43, Adrian Chadd <adrian@creative.net.au> wrote:

> > say:
> > cache_dir ufs /var/cache1 100 16 256
> > cache_dir fifofs /var/cache2 100 16 256
> >
> > cache_dir_conf /var/cache1 maxfile: -1 minfile: -1
> > cache_dir_conf /var/cache2 maxfile: 16K minfile: 512 acl: some_regex ..
> >
> > this would also allow us more possibilities in the future.
> > for eg. for some FS'es L1/L2 setup don't have any meaning
>
> Perhaps. But I think the -1 change is going to be a lot simpler than
> requiring everyone to add a cache_dir_conf line later on.

 typical user will never need to tune that "-1" from default. Why force
 them to change config file for upgrade, and back if downgrade?
 Also, if we need maxfilesize, then probably in very near future we'd want
 minfilesize as well. Also, we might want to specify replacement policy
 per FS, diskload limits, ACL's, etc. we'd need to add such option
 anyway, then why brake existing one now?

> Perhaps stuff like this requires a nested parser? :-)

 not sure what you mean, but don't we have a parser for options
 already (cache_peer [options] )?

====
I think Adrian means that the parser needs to be dependent on the found fs - which it already is. However I like the idea of adding
a cache_dir tuning parameter, particularly as some fs's may not even have a sensible cache_dir to refer to - and thus the common
settings are minimal.

Rob
Received on Thu Feb 01 2001 - 14:27:39 MST

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