Cache invalidation and cache.config

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

The documentation on ATS cache architecture mentions that most changes to storage.config or cache.config will invalidate the cache.

What is it about cache.config that affects the cache structure?

It seems though volume.config should be included in this list as well. Will volume changes invalidate the cache too?

Thanks,
Eric

Re: Cache invalidation and cache.config

["Kapil Sharma (kapsharm)" <ka...@cisco.com>]

Thanks for the link, James!!

Don’t know what I was thinking, but I went back and looked at the code to understand the what that paragraph was saying  (In particular Vol::init and build_vol_hash_table functions in Cache.cc). From what a mere mortal can I understand, it looks like:

- the Stripe assignment logic is *not* based on consistent hash algorithm
- it is some kind of pseudo random process , and seems to have deterministic properties (well, as long as there are not disk failures or additions.)
- One change in storage.cfg or a disk failure can (if I understand correctly) cause significant changes in assignments, and thus cache invalidation.

I have been banging my head trying to understand how is it that adding “id” field can mitigate the data churn due to hardware changes e.g if a disk fails, and after a reboot the order or disk path changes. It seems to me only thing “id” field does  is change the MD5 seed string from path to ‘id’. Unless id is somehow sticky to a particular disk, i don’t see how does it can prevent churn.

Please pardon my ignorance,  I may be completely off base!





> On Aug 16, 2016, at 5:57 PM, James Peach <jp...@apache.org> wrote:
> 
> 
>> On Aug 16, 2016, at 2:40 PM, kapsharm@cisco.com wrote:
>> 
>> Related question:
>> 
>> Would adding/deleting an entry in storage.cfg (e.g. adding a line /dev/sdx) invalidate the whole cache OR is the impact only to the entries that get mapped/re-assigned to new Vol/slices due to (consistent?) hash?
> 
> See https://docs.trafficserver.apache.org/en/latest/admin-guide/files/storage.config.en.html#assignment-table and the discussion about the "id" option. If you set the "id" then you can minimize the data churn.
> 
> 
>> 
>> On 2016-08-16 17:13 (-0400), James Peach <jp...@apache.org> wrote: 
>>> 
>>>> On Aug 16, 2016, at 5:39 AM, Eric Friedrich (efriedri) <ef...@cisco.com> wrote:
>>>> 
>>>> The documentation on ATS cache architecture mentions that most changes to storage.config or cache.config will invalidate the cache. 
>>>> 
>>>> What is it about cache.config that affects the cache structure?
>>> 
>>> Nothing AFAIK. Can you file a documentation bug?
>>> 
>>> https://issues.apache.org/jira/browse/TS
>>> 
>>>> It seems though volume.config should be included in this list as well. Will volume changes invalidate the cache too?
>>> 
>>> I'll defer to Alan on this, but I'm pretty sure that changing the volumes would invalidate the cache.
>>> 
>>> J
> 

Re: Cache invalidation and cache.config

[James Peach <jp...@apache.org>]

> On Aug 16, 2016, at 2:40 PM, kapsharm@cisco.com wrote:
> 
> Related question:
> 
> Would adding/deleting an entry in storage.cfg (e.g. adding a line /dev/sdx) invalidate the whole cache OR is the impact only to the entries that get mapped/re-assigned to new Vol/slices due to (consistent?) hash?

See https://docs.trafficserver.apache.org/en/latest/admin-guide/files/storage.config.en.html#assignment-table and the discussion about the "id" option. If you set the "id" then you can minimize the data churn.


> 
> On 2016-08-16 17:13 (-0400), James Peach <jp...@apache.org> wrote: 
>> 
>>> On Aug 16, 2016, at 5:39 AM, Eric Friedrich (efriedri) <ef...@cisco.com> wrote:
>>> 
>>> The documentation on ATS cache architecture mentions that most changes to storage.config or cache.config will invalidate the cache. 
>>> 
>>> What is it about cache.config that affects the cache structure?
>> 
>> Nothing AFAIK. Can you file a documentation bug?
>> 
>> https://issues.apache.org/jira/browse/TS
>> 
>>> It seems though volume.config should be included in this list as well. Will volume changes invalidate the cache too?
>> 
>> I'll defer to Alan on this, but I'm pretty sure that changing the volumes would invalidate the cache.
>> 
>> J

Re: Cache invalidation and cache.config

["kapsharm@cisco.com" <ka...@cisco.com>]

Related question:

Would adding/deleting an entry in storage.cfg (e.g. adding a line /dev/sdx) invalidate the whole cache OR is the impact only to the entries that get mapped/re-assigned to new Vol/slices due to (consistent?) hash?



On 2016-08-16 17:13 (-0400), James Peach <jp...@apache.org> wrote: 
> 
> > On Aug 16, 2016, at 5:39 AM, Eric Friedrich (efriedri) <ef...@cisco.com> wrote:
> > 
> > The documentation on ATS cache architecture mentions that most changes to storage.config or cache.config will invalidate the cache. 
> > 
> > What is it about cache.config that affects the cache structure?
> 
> Nothing AFAIK. Can you file a documentation bug?
> 
> https://issues.apache.org/jira/browse/TS
> 
> > It seems though volume.config should be included in this list as well. Will volume changes invalidate the cache too?
> 
> I'll defer to Alan on this, but I'm pretty sure that changing the volumes would invalidate the cache.
> 
> J

Re: Cache invalidation and cache.config

[James Peach <jp...@apache.org>]

> On Aug 16, 2016, at 5:39 AM, Eric Friedrich (efriedri) <ef...@cisco.com> wrote:
> 
> The documentation on ATS cache architecture mentions that most changes to storage.config or cache.config will invalidate the cache. 
> 
> What is it about cache.config that affects the cache structure?

Nothing AFAIK. Can you file a documentation bug?

https://issues.apache.org/jira/browse/TS

> It seems though volume.config should be included in this list as well. Will volume changes invalidate the cache too?

I'll defer to Alan on this, but I'm pretty sure that changing the volumes would invalidate the cache.

J