Cache problems report form, for a cache users complains?

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Wed, 28 Aug 2013 13:03:26 +0300

I was wondering about something.
For now we do not implement let-say metalinks support integrated inside
squid..
Do we have any mechanism that actually do a md5\sha1 etc. check on a
specific file that is in cache?

I wrote a small helper long ago that extracts the data of an object from
a UFS\AUFS store file.
The above also allows iterating over all UFS\AUFS cache_dir files and
delete the actual object from cache.
The above option can be used to also verify the integrity of a file in
the HASH level.
The helper can find the object and then verify the object\file data
without all the headers and metadata and make sure that it fits MD5\SHA1
hash..

A scenario that I was thinking about was that when StoreID is being used
there is a small problem to verify the content of each node in the
mirror pool... has the consistent copy of the directory.
metalinks can contain info/data on a single and multi files and multi
chunks.

A admin that wants to use StoreID I believe that will want to know if
his setup causing a trouble to the users.
A nice Idea I had was to use a "cache problem form" for cases that the
user has an issue and then the cache admin can try to investigate the issue.
The basic assumption to that is that not all mirrors are updated or
maybe in a case of a file corruption from a disk failure or any other
issues the admin will want to know about that.
Maybe adding a header to the client like "in a case of troubles contact
us using xyz" ??(similar to some facebook privacy headers)

I want to hear your opinion about it from an angle which is not mine
only. pros?cons?

I know that for most filtering solutions they do hava a cgi script to
report a problems..
Or in other places there is 302 redirection into a specific block page
to a form or other option that can help the user and the admins to
identify holes or over-filtering scenarios.

Eliezer
Received on Wed Aug 28 2013 - 10:04:03 MDT

This archive was generated by hypermail 2.2.0 : Wed Aug 28 2013 - 12:00:33 MDT