Re:Re: Squid storage method is redundancy?

Thanks, Adrian pal!

In your reply, you mentioned the following:

/////////////////////////////////////////////////////////////////////
When the server feeding data or the client reading data have finished,
the StoreEntry gets removed from the store client, and (eventually)
the store_client goes away.
/////////////////////////////////////////////////////////////////////

When you are mentioning "gets removed" from storeclient, do you mean the StoreEntry
removed from disk? Or do you mean just removing the reference of the storeclient of
the StoreEntry? ( I think it is the latter. Am I correct?)

When you are mentioning "store_client goes away", do you mean removing store_client
from disk? Or do you mean just removing the reference of the store_client to the StoreEntry
and keep the storeclient on disk? (I think it is the former. Am I correct?)

Best regards,
George, Ma

----- Original Message -----
From: Adrian Chadd
To: maer727@sohu.com
Subject: Re: Squid storage method is redundancy?
Sent: Tue Apr 09 12:42:29 CST 2002

> On Tue, Apr 09, 2002, maer727@sohu.com wrote:
> > Hi, pals.
> >
> > I am using Squid 2.4 STABLE.
> >
> > Squid use StoreEntry to store the metadata of a cached
> > object. Each StoreEntry has a list of storeclients. And
> > each of the storeclient has a reference to the object
> > on the disk/mem. So, each storeclient ( belongs to the
> > same StoreEntry ) has a reference to the same object on
> > disk/mem. Is that a redundancy?
>
> No. the store_client is for _open_ storeentry "entries".
> If the StoreEntry has been writeen or read completely,
> and its public, it won't have a store client.
>
> Imagine it like this.
>
> You have a big hash of StoreEntry's.
>
> Each StoreEntry is either private (the response isn't cacheable)
> or public (the response is cacheable). The public entries go into
> the hash, the private ones don't.
>
> When you create a StoreEntry you will have a store client to feed
> data into it (via storeAppend()).
>
> When you want an object, via storeLookup(), it looks at the hash,
> grabs the entry, knows that its public, attached a store client,
> and lets the client read (via storeClientCopy()).
>
> When the server feeding data or the client reading data have finished,
> the StoreEntry gets removed from the store client, and (eventually)
> the store_client goes away.
>
> Thats a simplistic view. Its not totally accurate (I haven't mentioned
> mem_obj's, which contain part or all of the object data) but it gives
> you an indication of what the bits do.
>
> > Why not just store the reference to the object in the
> > StoreEntry? (Now Squid just store metadata of object in
> > StoreEntry, like timestamp).
> >
> > Anyone has different opinions?
> >
> > Best regards,
> > George, Ma
> >
Received on Mon Apr 08 2002 - 23:12:19 MDT