On 2/3/2013 8:29 PM, Alex Rousskov wrote:
The cause of this specific problem is_not_ rock behavior (correct or
not) but a mismatch between a startup script and squid.conf -- the
script does not test for all the right directories when running squid-z.
Even if rock code is changed, this mismatch still needs to be fixed.
Please consider filing a bug report with Debian/Ubuntu if it is their fault.
To be consistent with ufs, we should probably change rock behavior from
initializing the database to doing nothing if the configured database
directory already exists. Like ufs, rock will rely on directory
existence for that test (regardless of what may be inside that
configured directory). In other words, squid-z is not "validate and
initialize" but "initialize if the configured directory is not there".
Any objections to that rock change?
My starter assumption was that squid -z erase or reset any cache_dir.
Then I found out it's not like that.
The init scripts checks for directories AND FILES but is not smart
enough to verify the integrity of the content.
So now the question is:
If squid has the ability to verify the cache_dir structure and DB more
then an init script, Why do we even let the script decide this kind of
decision?
Squid in any case rebuilds ufs stores or fix if corrupted or not?? right?
Why squid should not create a cache_dir if one dosn't exits at startup?
What side effects can come from that?
It can more complex but a "check", "reset", "build" flags can be added
to the -z like in -k parse|...|..| while having a default to "build"
which is what it does's now.
The "build" will be the default and compatible with the current -z flag
works.
The "check" can respond to an init or any other script a more
informative way about the check like 1 is bad 2 is something dirty 3
there is not store present 4 DB corrected.
I just think loudly since the subject was opened.
--
Eliezer Croitoru
http://www1.ngtech.co.il
