Alex Rousskov wrote:
...
> A similar question would be "where does the replacement policy fit?".
> I suspect that may have to be a part of the FS layer.
...
> One could argue that FS may benefit from knowing that two blobs belong
> to the same object.
a) You need some method of knowing which blobs you may have for a
object, and what they represent.
b) It must be decided if removal policy is performed on these blobs
individually, or on objects as a whole.
> On the other hand, FS could also benefit from
> knowing the relations between HTML container and embedded images, etc.
> So we would come back to our "keep it simple/smart" discussion.
Sure. Both ways ;-)
> I
> suspect that eventually we might add a third parameter to the store
> interface:
> store(key, blob, related_to_keys)
> just to give some FSs additional hints for dataplacement while keeping
> the interface simple and abstract.
Actually I would like to have the store interface a bit more elaborate
than that. Currently we have two classes of object bits that we need to
deal with:
a) Data ranges (encoding of these is not relevant; ranges, chunks, or
whatever. Same thing)
b) Variants (collections of ranges)
All of these share a common key (the URL).
Both types needs to be able to handle additions where an additional data
range or variant is added to the URL.
I think removal policy should work at the level of variants. I don't
think it is practical to apply removal policies to individual data
ranges.
/Henrik
Received on Wed Dec 13 2000 - 22:07:01 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:04 MST