Re: Re: Squid storage method is redundancy?

The storeclient doesn't get removed from the disk. Its never on the
disk.

Its just the "open file handle" used to track which client(s) are
currently attachedto a storeentry, and where they're up to
in reading/writing.

When they've finished with the data, the client goes away, and so does
the store client.

The StoreEntry, which references a cache object, exists on the
disk if its public and cacheable.

adrian

On Tue, Apr 09, 2002, maer727@sohu.com wrote:
> 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:27:09 MDT