[squid-users] rock storage integrity

[Alex Rousskov]

On 12/04/2015 08:37 AM, Hussam Al-Tayeb wrote:
> Since this is a database, it is possible for part of the database to
> get corrupted through a crash or incorrect poweroff?

It depends on your definition of "corruption". Yes, it is possible that
some database updates will be incomplete because of a poweroff. Bugs
notwithstanding, after a restart,

* Squid will not notice that an entry that was supposed to be deleted
was not. Squid will continue to serve such an entry from the cache.

* Assuming atomic single-write disk I/Os, Squid should notice an entry
that was only partially saved and not serve it from the cache. Its slots
will be considered free space.

* In the event a single-write disk I/O was only partially completed,
Squid may or may not notice a partial save, depending on what was
actually written to disk. There is currently no Squid code that detects
non-atomic single-write disk I/Os. AFAICT, this might corrupt up to two
cache entries per cache_dir in such a way that Squid will not notice the
corruption unless there are some OS-level protections against that.
Squid uses regular file system calls for writing entries...

* There should be no effect on entries already fully stored at the time
of the power outage.


> I had an incorrect poweroff yesterday but cache.log did not list
> anything weird.

> Nevertheless, what would be the best way to check if there was some
> damage to the database (unusable slots/cells/whatever)?

IIRC, for Rock, all validation is currently done automagically upon startup.


HTH,

Alex.