<div dir="ltr">Hello Alex,<div><br></div><div>Thank you for the explanations.</div><div><br></div><div>Could you tell me if there is a way to view the objects (URLs) and their statuses stored in the rock file?</div><div>I tried unsuccessfully to find this information using squidclient in mgr:menu.<br></div><div><br></div><div>You gave me a very useful link: <a href="https://wiki.squid-cache.org/Features/LargeRockStore">https://wiki.squid-cache.org/Features/LargeRockStore</a></div><div>Maybe there is a more detailed description of the internal rock data structures?</div><div>I could try to write a script that reads the necessary information from the cache_dir file.<br></div><div><br></div><div>Kind regards,</div><div>     Ankor.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 5 апр. 2023 г. в 16:27, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/5/23 06:07, Andrey K wrote:<br>
<br>
> Previously, caching was disabled on our proxy servers. Now we need to <br>
> cache some content (files about 10 MB in size).<br>
> So we changed the squid.conf:<br>
<br>
> cache_dir ufs /data/squid/cache 32000 16 256 max-size=12000000<br>
> <br>
> We have 24 workers on each proxy.<br>
<br>
UFS-based cache_dirs are not supported in multi-worker configurations <br>
and, in most cases, should not be used in such configurations. The <br>
combination will violate basic HTTP caching rules and may crash Squid <br>
and/or corrupt responses.<br>
<br>
<br>
> We saw that some requests were taken from the cache, and some were not.<br>
> The documentation says:<br>
> "In SMP configurations, cache_dir must not precede the workers option <br>
> and should use configuration macros or conditionals to give each worker <br>
> interested in disk caching a dedicated cache directory."<br>
<br>
The official documentation quoted above is stale and very misleading in <br>
modern Squids. Ignore it. I will try to find the time to post a PR to <br>
fix this.<br>
<br>
<br>
> So we switched to a rock cache_dir:<br>
> cache_dir rock /data/squid/cache 32000 max-size=12000000<br>
> <br>
> Now everything seems to be working fine in the test environment, but I <br>
> found limitations on the RockStore <br>
> (<a href="https://wiki.squid-cache.org/Features/RockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/RockStore</a>:<br>
> "Objects larger than 32,000 bytes cannot be cached when cache_dirs are <br>
> shared among workers."<br>
<br>
The Feature/RockStore page is stale and can easily mislead. In general, <br>
Feature/Foo wiki pages are often development-focused and get stale with <br>
time. They cannot be reliably used as a Squid feature documentation.<br>
<br>
<br>
> Does this mean that RockStore is not suitable for caching large files?<br>
<br>
No, it does not. Rock storage has evolved since that Feature page was <br>
written. You can see the following wiki page discussing evolved rock <br>
storage design, but that page probably has some stale info as well:<br>
<a href="https://wiki.squid-cache.org/Features/LargeRockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/LargeRockStore</a><br>
<br>
<br>
> Should I switch back to the UFS and configure 24 cache_dirs<br>
<br>
If everything is "working fine", then you should not. Otherwise, I <br>
recommend discussing specific problems before switching to that <br>
unsupported and dangerous hack.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>