On 17/10/17 07:05, Alex Rousskov wrote:
On 10/16/2017 09:23 AM, Amos Jeffries wrote:
The -z process for
rock caches actively formats the file used for data storage into cells
and blocks.
Not really. "squid -z" adds a small db header, but the rest of the
database is assumed to be nothing but zeros. Squid -z used to fill the
whole db file with zeros (see SLOWLY_FILL_WITH_ZEROS), but I believe we
stopped doing that (by default) and expect an "enlarging truncate" to
have the same side effect. The comit log may have more info about that.
Oh, I thought each block had a TLV and checksum bits as well.
Changing its size manually will definitely lead to some form
of corruption.
What makes you think that? Bugs notwithstanding, there are three cases
to consider AFAICT:
* Adding a partial empty slot should be a no-op because Squid will not
notice the added space after rounding the number of slots down.
* Adding a full all-zeros slot will not affect any data already stored
in the database -- nothing will point to that new slot. It will be used
for new cache entries.
* Removing a slot, whole or partial, will invalidate the cache entry
that was using that slot (if any). The affected entry will not be added
to the shared memory index. Skipping an entry should not lead to cache
corruption. It will lead to loss of cache data (and probably some
warnings) but that was explicitly allowed in the original question.
This last one was what I was referring to as corruption. Though I expect
that *removing* slots would lead memory index pointing to no longer
valid locations in the rock database.
Is it harmless to access out-of-range offsets into a memmap'ed file -
specifically ones which *were* valid when it was initially mapped?
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
