[squid-users] Is it safe to resize a rock storage file?

[Amos Jeffries]

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