On 10/03/2017 5:19 a.m., Matus UHLAR - fantomas wrote:
>> On 03/09/2017 07:21 AM, Matus UHLAR - fantomas wrote:
>>> I have installed squid 3.4.8 on linux 3.16/64bit (debian 8 / jessie
>>> version)
>>>
>>> (I know it's old, but I prefer using distribution-provided SW unless
>>> it has
>>> real problem distribution isn't able to fix)
>
> On 09.03.17 09:07, Alex Rousskov wrote:
>> My answers are based on v5 code. (I know v5 is new, but I do not
>> remember v3.4 specifics and v5 answers will be valid for a longer time.)
>
> OK
>
>>> I configured rock store (for smaller files) and (later) standard aufs
>>> for others:
>>>
>>> cache_dir rock /var/spool/squid3/rock 1024 max-size=32768
>>> #cache_dir aufs /var/spool/squid3 8192 16 256 min-size=32769
>>>
>>> are those correct values? (bug 3411 says something about 256B metadata)
>
>> Both rock and AUFS stores support large objects so there is no
>> requirement to split storage based on object sizes. Each store has
>> various pros and cons, but lack of large object support is not one of
>> the distinguishing characteristics.
>
> I thought the cons of *ufs/disks is ineffective storage of small files,
> while rock is ineffective with big files...
>
Yes, *efficiency*, not lack of support.
[except in this case of your 3.4 where rock does explicitly lack the
support].
>>> - do I get it right that kid1 is the Master, kid2 is the disker for rock
>>> store and kid3 is the single worker process?
>>
>> In SMP mode (which, BTW, AUFS store does not support),
>
> could it crash squid instead of complaining?
Are you talking about when AUFS is used in SMP mode? it is not that
simple, there are ways to configure it to be used by a single worker
("if" directive, or $(process_number) macro) which is fine and work well
for certain version-specific situations.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
