The code below the warning does not run if the configuration variable
proxy.config.cache.min_average_object_size is set correctly,
so you should never get to this code under normal operation.
It is therefore an emergency code path to ensure that the cache
can continue in some capacity.

Because of the way the directory works it is impossible to forward chain
and find the other parts of a document just using the directory, and
because this is an emergency situation it is not practical to read each
document from the disk to find the next directory entry.  It is true that
stale directory entries for successive parts of a document may remain
but again, this should not run in normal operation and the stale entries
will eventually get cleaned up as the cache recovers the space they point to.

I don't know where the design documentation is, perhaps someone else
can help you with that.

john

于佳华 wrote:
> hi, developers
>      I am a Chinese student. I am very interested in the cache implement of
> "TS", and I have read TS's code for several days. I note that TS write a
> item with a "full-index" mode: throug the CacheKey to find
> part->segment->bucket and write in a part of the item to a dir. If
> conflicting, there is a link "dir->next" to store all data having same
> index. But when the cache is full, TS will execute the code in
> "cachedir.cc":
> 
> void
> freelist_clean(int s, Part * part)
> {
>   dir_clean_segment(s, part);
>   if (part->header->freelist[s])
>     return;
>   Warning("cache directory overflow on '%s' segment %d, purging...",
> part->path, s);
>   int n = 0;
>   Dir *seg = dir_segment(s, part);
>   for (int bi = 0; bi < part->buckets; bi++) {
>     Dir *b = dir_bucket(bi, seg);
>     for (int l = 0; l < DIR_DEPTH; l++) {
>       Dir *e = dir_bucket_row(b, l);
>       if (dir_head(e) && !(n++ % 10)) {
>         CACHE_DEC_DIR_USED(part->mutex);
> 
>         dir_set_offset(e, 0);   // delete
>       }
>     }
>   }
>   dir_clean_segment(s, part);
> }
> 
> this means TS just remove some head dirs by traversing, not care the heat of
> the dir and not remove other dirs belong to the same item of the head dir.
> 
>    The document says "When the cache is full, Traffic Server removes stale
> data, ensuring that the most requested objects are kept on-hand and fresh.".
> I want to consult how TS implement it and where stores the hit-number of one
> item.
> 
>    And, is there some more document about the TS architecture?
> 
>   Thanks a lot.
> 
> 
> 
> Flame Yu
> 

Reply via email to