Configuration dCache pour CMS
    Réunion du 2/04/2009
##############################

T0D1 [REPLICA/ONLINE]: 
  - LoadTest   
   
   cms/data/store/PhEDEx_LoadTest07          | class = disk-sc3
   *  pools = pgroup-disk-sc3  
  - Prod  75TB  
   cms/prod                                  | class = prod
   *  pools = pgroup-cms-prod


T1DO [CUSTODIAL/NEARLINE]:

   /data/store/data/Commissioning08/Cosmics/RAW        |
   /data/store/data/mc/CSA08/MuonPT5/GEN-SIM-RAW       |  class=raw

   /data/......../RECO                                 |
   /data/mc/...../GEN-SIM-RECO                         | class=reco

   /data/store/data                                    | class=hpssdata


   * pools = pgroup-cms-hpssdata
   
   3 Réservations T1D0 : CMS_DEFAULT ; CMSCUSTODIAL ; "Sans Spacetoken"

   CMSCUSTODIAL : 
     - Données dont nous sommes responsables
   CMS_DEFAULT :
     - reçoit les données du CERN dont on n'est pas responsable (pas le site principal).
     - en théorie, T0D1 mais pour des groupes locaux, ces données ont un intérêt.
     - doit peut-être passer en T0D1. Il faut voir avec C. Charlot.

   Concurence d'accès en écriture entre les jobs qui écrivent en T1D0 (sans spacetoken) et les transferts CMSCUSTODIAL :
     - faut-il scinder l'espace T1D0 en 2 groupes de pools et répartir les réservations différemment ?
     - quels spacetoken les jobs utilisent-ils ?
     - Il faut qu'on fasse une proposition pour cela

Questions subsidiaires (mais importantes) : 

- Comment éviter que des utilisateurs T2 surchargent HPSS :
   * Peut-on écrire les AOD sur disque ? ... Farida va le déterminer
   * Limiter les ressources d'utilisateurs T2 
   * Utiliser le T2@CC et faire des replicas sur un espace T0D1.  => /pnfs/in2p3.fr/data/cms/tier2/ .....
      Il faut pour cela évaluer l'activité.
   * Stocker les AOD en T1D1


Conclusion :

 - CMSDEFAULT sur T1D0 ?
 - Séparation de l'espace T1D0 pour les accès des jobs
 - Accès aux données par le T2@CC