Re: Hot object cache

On Monday 21 October 2002 07.10, Robert Collins wrote:

> > Having the assumtion that a FS layer must be able to swap in data
> > while it the same is beeing swapped out is not a trivial
> > assumtion and quite likely to be error prone.
>
> Actually, it's quite simple if you layer it right. The only
> assumption I'm making is that data that has been swapped out can be
> retrieved - which seems reasonable to me :}.

> Yes, and we can deal with that when those changes are ready. IMO
> this will not impact the index issues. The storeSwapper will not be
> part of the fs layer or the store itself.

As long as you deal with the situation where the FS layer won't give
you a swapin handle if it doesn't agree that this is a reasonable
assumption it should be more or less fine, and we can deal with the
details later.

> > Saving the merged object as a new StoreEntry makes cache
> > transactions much more well defined. If we later find that this
> > generates a considerable amount of copying then lets try to
> > address "in-place merges" then, but before we do index management
> > should have been moved down to the FS layer.
>
> Why? This is orthogonal.

Index management also involves that the FS layer keeps track of where
the data can be found within the FS, not only which objects are
there. If you start adding FS functions to manipulate existing
objects these may need to manipulate the index.

> I don't have a specific view of StoreEntry. It is very over used in
> squid, and that is one of the things I am refactoring, making it
> clearer what is a StoreEntry, what is a store client, what is a mem
> object etc.

Good.

> I think we need something that is returned when a client gets data
> about a cached object. THAT thing may as well be called StoreEntry.

Ok.

Why do you need such a object? In what ways is it different to the
store client from a object retreived from the network?

Regards
Henrik
Received on Mon Oct 21 2002 - 03:26:34 MDT