[glue-wg] Datastore proposal

[Maarten Litmaath]

Burke, S (Stephen) wrote:

>>>Type (disk, tape, ... - open enumeration)
>>
>>... which we would define the common types, right?
> 
> 
> Yes - but do we have anything common apart from tape and disk? dvd?

I think we should at least foresee dvd, and keep it open-ended.

>>>one Datastore can
>>>only be managed by one Resource - if there are e.g. multiple sets of
>>>disk servers managed by several different software systems 
>>
>>that would constitute multiple Datastores.
>>
>>OK, I think, but it might depend on the "management" aspect 
>>of Datastores.
> 
> 
> Can you elaborate? As I said earlier we have the situation at RAL that
> all the different Castor instances (Resources) share a common tape
> system, but I think that's too complicated to deal with, we should just
> treat it as multiple tape Datastores.

Agreed.

>>This link would be optional one-to-many: each 
>>StorageShare is 
>>associated with a single Datastore (0..1 multiplicity) and 

I may have commented on that proposal already: I do not agree with it.
A StorageShare can be associated with several (independent) Datastores,
each providing a storage technology that is needed by the Share.
For example, one Datastore for the disk and another for the tape.

>>each Datastore is 
>>associated with any number of StorageShares (0..* multiplicity).
>>
>>Would that be acceptable?
> 
> 
> Well ... rather than making Share <-> Datastore *..* you could consider
> defining three separate Share <-> Datastore relations, one for each of
> Online, Nearline and Offline, and each of which would be *..1. However,
> that would imply that the storage for a Share for a given Latency can
> only be provided by one Datastore, and I suspect that you can't be sure
> of that in all cases. An example could be LCG-style Online/Custodial
> D1T1 where you have three Datastores: tape, disk cache in front of the
> tape, and permanent disk (I think this is what CNAF has?).

For D1T1 we should not publish any hidden cache in front of the tape:
that cache is an optimization that the client has no control over
(one cannot pin files in it).

Can we collapse the tape with the cache into a single Datastore that has
both an Online and a Nearline component?

If not, I suppose we can collapse cache with disk if we do not care about
the semantic differences at that level.