Those present reviewed possible storage service classes that could be provided by storage systems
to see which were relevant for the LHC experiments. In the interest of time, we concentrated on
storage of large production data files rather than user files. The list of possible service
classes is shown in the attached document. Service classes in bold font were identified as required
for SC4, greyed out service classes were thought to be of little relevance even in the long
term.
Three possible options for the experiments to specify which storage class to use were also
discussed, although rather briefly.
It was agreed that
- For SC4 only
- Glue schema storage types “permanent” and “durable” should be used to refer to tape
backed up storage (e.g. for raw data) and disk resident storage (e.g. ESD files) respectively
- as there are only two service classes, these are distinguished by using an SRM endpoint for
each.
- In the long term
- Mass storage system providers, site representatives and experiments should agree a full
classification of all the storage types, assigning a name to each. It was considered that we can
add SRM types to refer to these once this is done, although care has to be taken for sites which
support non-HEP users where issues other than file safety and ease of access are relevant (e.g.
data can be deleted automatically after a set period of time without informing the user).
- Following this, agree an efficient/effective way for users to select amongst the available
storage classes.
[Discussion Monday during coffee (Tony, Don, Timur, Don, Graeme): multiple SRM endpoints look
difficult, but probably not required. Advertise multiple Storage Areas (SAs) (with GlueSAType
durable or permanent), each of which has an associated path which is VO specific. To be discussed
internally by each storage system provider; response in next 10days.
Note: This is in context of SRM 1.1, not SRM 2.1. which won\'t be used for (start of) SC4.]
Still the case that long term solution is to be decided.
At the closeout session on Monday, it was agreed that system providers should return with a
proposal of how the GlueSAType can be advertised (see attached Glue considerations document). It
was further agreed that
<sl>
A clear message should be given to the experiments on how to intercase with the SRM 1.1 client
(i.e. how does fts/gfal interface to this?)
SC4 starts without SRM 2.1. SRM 2.1 interfaces to storage systems must support whatever is
agreed as the future ontology/access system, but must still aim for October as the deadline for
introducing an SRM 2.1 service.
Sites without tape must advertise their GlueSAType as durable.
A plan for the migration from SRM 1.1 to SRM 2.1 must be prepared. In particular, this must
explain how to deal with the experiment catalogues. (catalogue stores reduced SURL; does anything
change in what is stored—e.g. endpoint, …???)
Maarten Litmaath will coordinate/chair future meetings and is responsible for ensuring
agreement and delivery of the SRM servers by September.
</sl>