* Artem mentions that in CMS computing TD it is foreseen that 85% of disk
space at T1 is for analysis data, and only 15% of disk space is for staging
of raw and other types. This starts discussion on storage groups for
different types of data.
Mark: Need to be intelligent in staging, to minimize tape mounts. May want
to make Tier-1 sites to drive reconstruction?
Michael: Prestaging will be centrally managed.
Mark: better create storage groups for experiments, in order to cluster
data on tapes by type. Atlas is doing this. Then can chose how stagin is
done for these storage groups. For example, can read the whole tape with
raw data if one file is requested.
> > atlas/data/raw
> > /esd
> > /aod
> > /tag (if flat files are used instead of DB)
> > /log (a log dir could sit under its associated
> > data type too)
> >
> > atlas/mc/hits
> > /digi
> > /hists
> > /aod
> > /etc.
Michael: absolutely, CMS will do it to smoe extent.
Jos: need formal descriptions for all experiments, and need to force it.
All: raw - for sure. Then perhaps: reco, aod, MC?
Michael: it a minimun. May even need to create separate storage classes
e.g for each MC release, mode etc.
* Discussion on Tape1Disk1 srm storage class.
Mark: How is it implemented in dCache?
Michael: 2 pools: one migratable to tape, another disk resident.
Mark: but duplication? Will files be in different dirs? will they have
multiple pnfs entries?
Michael: it's a matter of implementation, basically, trust the system, it
will do it for you. It's all automatic. One pnfs entry.
Artem: asked Patrick Fuhrmann, he will describe implementation of
Tape1Disk1 class in details.
* Transfer vs. processing buffer
Artem mentions that it could be usefull to further split anlysis buffer
and allocate "reprocessing" buffer, where data with high staging turnover
will be held (raw).
Jos: we can do it, if requested, but need to keep in mind common setup for
all experiments.
* SRM endpoins discussion
Artem mention, that CMS may go toward single srm endpoint + LFN, where
LFN has a VO-defined structure , but this is not enforced.
Jos: Nice to have, but having more srm end points may allow tospread the
load.
Michael: it's a matter of publishing too. App need to kow how to use those
mutliple end points.
Jos: ok, but we a groupd could findtechnical reasons for multiple end
points.
Micheal: Need a possibility to accomoddate it, butnot exclude having just
one.
Mark: and the dir structure in case of mutlipleend points?
Artem: should be different, i.e. a unique dir under on end point,
Jos: about LFN naming convention: can't we come up with a single naming
scheme across experiments? Define certain data types in VO LFN hierarhy?
Artem: very inconvinient for the VOs.
Michael: None need to do this, but to data type - dir mapping to storage
groups.
Mark: better move data types to the of hierarhy.
* Finalising discussions:
Jos sugests to summarize the questionaire.
Artem reviews Kor's topic list and promised to write up the progress on
the group so far.