Why cannot the same path for cache be used several times?

Wandenberg Peixoto wandenberg at gmail.com
Thu Aug 7 04:00:45 UTC 2014


Hi,

The key_zone is just the name of a shared memory area where some metadata
about the cache entries will be saved.
The files stored on the cache_path does not use the key_zone.

They are different configurations to two different purposes.

To do what you are imagining, the file stored on cache_path must have the
key_zone on its name, something like

/tmp/cache/*zone1*/0/00/9fc611e1a487c7a86585d509730f6000
/tmp/cache/*zone2*/0/00/9fc611e1a487c7a86585d509730f6000

Two different files saved on the same cache path, only using different
key_zones.

Since the key_zone is just a string on your configuration, if you now want
to rename them like
zone1 -> zoneA and zone2 -> zoneB
and restart your server, all the content on your cache would be lost,
because the paths /tmp/cache/zoneA and /tmp/cache/zoneB will be empty.

You can use the key_zone name on different locations, and all objects will
be saved on the same path.
To have different key_zone values you have to specify different cache_path.

I hope this hypothetical example helps to understand :)

Regards


On Wed, Aug 6, 2014 at 3:59 PM, B.R. <reallfqq-nginx at yahoo.fr> wrote:

> Thanks for your input Maxim.
>
> However either I still do not get the purpose of the zone key or I am
> missing something in the whole reasoning...
> Isn't it the zone key there to isolate requests from different sources and
> thus avoid collisions in the same cache path?
> The only case favorable for collision is, as you explained, when the same
> cache path *and* the same zone key are being used.
>
> If I am correct, why not allowing the same cache path to be used, provided
> the zone key is *always* different on each call of *_cache_path?
> ---
> *B. R.*
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140807/201c5e3c/attachment.html>


More information about the nginx mailing list