10–12 Feb 2006
TIFR, Mumbai
Europe/Zurich timezone

Session

Storage Types BOF

12 Feb 2006, 18:00
TIFR, Mumbai

TIFR, Mumbai

Description

The text below is now a summary of the BOF conclusions ordered logically; see the "minutes" link for a more faithful record of the discussions.

  1. It was agreed that the resaons for the volatile/durable/permanent distinction make little sense for HEP centres storing HEP data and that issues of interest to HEP physicists (is a file on tape, who manages the cache) are not covered.
  2. Although the discussions on the Sunday talked about changng the SRM specification (and this may indeed be done), discussions on the Monday and Tuesday focussed more on the Glue Schema which uses these same terms to describe Storage Areas which are provided by a Storage Element. Although the changing/extending the Glue schema could take some time, there is little to stop people using a new type ("fred") for these storage areas provided all agree what is meant by the new type name.
  3. One of the word documents attached here describes a list of possible storage types. If this list can be agreed to be exhaustive and names assigned to all types in the next week or so then fine. (It may be possible to pick [replacement] names for just the two initial SC4 classes, but time presses. The advantage would be that a migration from these names would therefore be avoided.) If not, we use durable and permanent as the sole storage types for the start of SC4, with the meanings as described there.
  4. The SRM 1.1 interface will be used for the start of SC4
  5. The consequence of points 3 & 4 is that HSM providers and sites must decide how permanent and durable storage areas can be implemented such that someone checking the information service can use the areas as required. This to be done by February 27th.
  6. Thereafter, HSM providers and sites have a little longer to name the different storage types and implement all of these in the SRM 2.1 interface. The target to have all of this done (and a migration path defined) such that we can move to the SRM 2.1 interface by October. SRM 2.1 interfaces that are not compatible with what is agreed are not to be introduced.
  7. Maarten Litmaath of CERN will be responsible for fostering discussions and convening meetings as necessary to ensure agreement for SRM 2.1 introduction in October.

Presentation materials

Building timetable...