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

[Alex Rousskov]

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.


> 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.

Please let me know if I missed something or if there are reasons to
believe there are bugs affecting the above logic.


Thank you,

Alex.