<div dir="ltr">Hi,<div>   I think it is reasonable to expand the number of objects Squid can manage. 32-bit systems are almost rare to come by nowadays.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 10, 2016 at 11:08 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/07/2016 1:37 a.m., Amos Jeffries wrote:<br>
> This patch converts the CacheDigest members and method parameters to use<br>
> explicitly sized data types more appropriate for what details they hold.<br>
><br>
> * 64-bit Digest capacity (entry count)<br>
> * 32-bit Mask Size (byte count)<br>
> *  8-bit Bit count per entry<br>
><br>
> Due to various store_digest.cc code still relying on masks not exceeding<br>
> 2^31-1 worth of memory space we have to still assert that bitCount<br>
> calculation does not exceed that value.<br>
><br>
<br>
</span>Additional to this, to fully fix the bug 4534 issue we are going to have<br>
to decide if it is reasonable to have extremely large Cache Digest masks<br>
(several tens of GB or memory).<br>
<br>
The caches the bug appears on are all several TB of size (by space). But<br>
even more importantly they are spread over more than 5 cache_dir. So the<br>
2^25-ish limit on entries per cache_dir is not keeping the total<br>
Squid-wide object count within a 32-bit value.<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">    Francesco</div>
</div>