<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 9, 2018 at 7:50 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
</span>I cannot answer your question for aufs, but please note that rock<br>
cache_dirs do not support/have/use a configurable replacement policy:<br>
Each incoming object is assigned a slot based on its key hash. With<br>
modern rock code, it is possible to remove that limitation IIRC, but<br>
nobody have done that.<br></blockquote><div><br></div><div>Yeah I figured this out from the source code and I'm extremely surprised by the fact that it was never mentioned in documentation. I think it will be a huge blocker in our squid 4 + SMP + rock migration plan.</div><div><br></div><div>So what does rock do when storage is full then?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
<br>
> If you're wondering why would we need to know that – it's related to<br>
> GDPR and removing data of closed customer's accounts. We need to make<br>
> sure that we don't have any "not being accessed anymore" objects older<br>
> than "data retention period" days.<br>
<br>
</span>If it is important to get this right, then I would not trust replacement<br>
policy metadata with this: The corresponding code interfaces look<br>
unreliable to me, and access counts/timestamps for a ufs-based cache_dir<br>
are not updated across Squid restarts when the swap log is lost (at least).<br>
<br></blockquote><div><br></div><div>It's actually fine, we never restart squid and if it restarted by any unexpected reason (host reboot, crash or w/e) we just replace the host.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would instead configure Squid to prohibit serving hits that are too<br>
old. That solution does not match your problem exactly, but it may be<br>
good enough and should work a lot more reliably across all cache_dirs.<br>
If there is no "age" ACL to use with the send_hit directive, then you<br>
may need to add one.<br>
<br>
    <a href="http://www.squid-cache.org/Doc/config/send_hit/" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Doc/config/send_hit/</a><br>
<br>
You may also be able to accomplish the same using refresh_pattern, but I<br>
am a little worroed about various exceptional/special conditions<br>
implemented on top of that directive. Others on this list may offer<br>
better guidance in this area.<br>
<br></blockquote><div><br></div><div>I was thinking about similar solution but this is exactly why I wasn't able to use it – there seems to be no acl suitable for such task.</div><div><br></div><div>We can always just replace the host every month or something like this but it'll mean starting with a cold cache every time which I wanted to avoid.</div><div><br></div><div>I found this debug option for heap which could probably help in understanding of approximate cache age but it doesn't work with rock because rock uses some "simple scan" policy.</div><div><br></div><div>> src/repl/heap/store_repl_heap.cc:        debugs(81, 3, "Heap age set to " << h->theHeap->age);</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
HTH,<br>
<br>
Alex.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">With best regards, Ivan Larionov.</div>
</div></div>