Re: [squid-users] hier_code acl and cache allow/deny

On Fri, Feb 21, 2014 at 12:13 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/15/2014 06:12 AM, Nikolai Gorchilov wrote:
>> I'm trying to avoid the following scenario (excerpt from store.log):
>>
>> 1392406208.398 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1
>> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET
>> http://www.gnu.org/graphics/t-desktop-4-small.jpg
>> 1392406242.459 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1
>> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET
>> http://www.gnu.org/graphics/t-desktop-4-small.jpg
>>
>> First request was served by kid1. It fetched the object by
>> HIER_DIRECT, memory cached it, and stored it to it's storage (say
>> /S1).
>> Seconds later, the same request arrives to kid2. It retrieves the
>> object from shared memory (hierarchy code NONE), then swaps it out to
>> it's own storage (say /S2).
>>
>> The question is how to prevent kid2 from saving the duplicate object?
>> Is there any mechanism other then switching memory_cache_shared off?
>
> Yes, rock store. If you get the above behavior while using rock
> cache_dirs (shared by all workers) and no other cache_dirs, then it is a
> bug.

Nope, it's aufs. Due to my stalled connections issue with the rock
store I'm forced to go with aufs for 32K. objects.

Niki
Received on Fri Feb 21 2014 - 03:09:26 MST