Les premières migrations batch ont débuté. Les transferts sont organisés par programme scientifique et type de données. Les batchs transfèrent les archives jusqu’à atteindre leur limite en termes de temps CPU (ou elapse) et se relancent automatiquement pour poursuivre les opérations.
Sur les premières évaluations, il faut environ 10 mn par archive FITS. Il y a près de 4 000 archives, mais grâce au mécanisme de batch, il est possible de lancer plusieurs migrations simultanément.
Le nombre d’opérations pouvant être réalisées en parallèle est à négocier avec les administrateurs du Centre, mais comme il n’y a que 7 programmes majeurs, regroupant 85% des données, il doit être acceptable de traiter tous ces cas en même temps.
La répartition des archives par programme scientifique n’est cependant pas équilibrée, et les deux plus importants comptent environ 1 500 archives chaque. Soit un temps très estimable, ou en tout cas estimé, de 15 000 minutes pour chacun de ces programmes, soit 250 heures, ou 10 jours…
Il reste cependant plusieurs points à préciser :
- fiabilité des batchs
- accès aux fichiers des archives
- organisation des données
- DAP
Fiabilité des batchs
La fiabilité des batchs reste un souci. Si le temps demandé est important, le batch est placé dans une file d’attente longue, et prend du temps avant d’être activé. Mais si le temps demandé est trop réduit, l’algorithme interne de détection de la limite du temps imparti est imprécis et le batch peut être interrompu brutalement avant de s’être relancé. En outre, le CC risque de ne pas apprécié de voir des petits batchs s’enchaîner – on risque de se faire taper sur les doigts…
Accès aux fichiers des archives
Une partie de la stratégie de migration consistait à indexer directement les fichiers des archives Tar dans le catalogue iRods. Cette approche ne fonctionne pas avec les archives Eros. Elles sont trop grosses et/ou contiennent trop de fichiers. Le problème, signalé au CC, a été confirmé. D’ailleurs, d’autres utilisateurs l’ont constaté. Ceci devrait être fixé dans une future version.
Il semble cependant délicat d’attendre cette correction. Le choix fait est donc de recopier les archives sur un disque local, d’en extraire les fichiers, de recopier les entêtes FITS dans des fichiers séparés, et de recopier tous ces fichiers dans iRods.
Organisation des données
La nouvelle organisation est donc la suivante:
iRods:
/eros/eros2/fits /eros/eros2/fits-headers /eros/eros2/fits-properties /eros/eros2/tars
SPS:
/sps/hep/eros/ErosTools/eros2/fits-headers /sps/hep/eros/ErosTools/eros2/fits-properties /sps/hep/eros/ErosTools/eros2/logs
DAP
Ou divers autres points (ce qui me semble préférable à AOB – qui fait un peu appellation contrôlée…).
Reste donc à débattre…
- Regroupement des différents blocs d’un suivi en un seul fichier
- Intégration des courbes de lumière conservées à Saclay
- Eros 2/plaques
- Eros 1