On 4/02/2013 7:54 a.m., Eliezer Croitoru wrote:
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.
The problem _is_ rock behaviour. Because it is initializing without
checking for existence. Erasing a working DB if the admin happens to run
squid -z without understanding its full operation.
-z should be able to run at any time without any major consequences.
I am completely in favour of adjusting -z to perform a validate by
default when possible.
However, that does not change the fact that rock is currently performing
an _erase_ operation when one exists.
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?
Absolutely none. Start by making both perform an existence check before
doing *anything*.
* initialize if it does not exist yet
* optionally perform validation + repair if something does.
UFS seems to scan the directory structure and create missing
sub-directories. Omiting the file corruption tests. We should probably
add these now that they are possible.
Rock should probably scan the potentially corrupt database and try to
drop/erase individual corrupt entries before deciding whether to
completely re-initialize the DB.
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?
Init scripts do this because Squid crashes on startup if the directories
do not exist, squid-2 packaged with a default cache_dir, and some
systems are automatically built using tools like puppet - drop config
files into /etc/default/$PROG ; install $PROG ; service start $PROG.
Less than 5 minutes from bare metal to operational server.
Squid in any case rebuilds ufs stores or fix if corrupted or not?? right?
"not". This operation is a todo list entry.
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.
