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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
