Sauvegarde des images calées

23 Décembre 2021

Les images Eros 2 calées par Jean-Baptiste ont été transférées au Centre de calcul et sont désormais sauvées dans Irods et référencées dans la base de données.

Pour mémoire, la nouvelle organisation dans Irods est la suivante:

Répertoires	Description
/eros/data/eros2/fits-astro	les images calées
/eros/data/eros2/headers-astro	les entêtes des images calées
/eros/data/eros2/fits	les images originales
/eros/data/eros2/headers-origin	les entêtes des images originales

1.570.116 images ont été transférées à Lyon pour un volume de 12 TB. Ces images appartiennent aux "7 Majeurs", c'est-à-dire BS (Beta Scuti: Bras spiraux), CG (Centre Galactique), GN (Gamma Normae: Bras spiraux), GS (Gamma Scuti: Bras spiraux), LM (LMC), SM (SMC) et TM (Theta Muscae: Bras spiraux).

Le transfert a pris presqu'un mois - 22 jours si on ne tient pas compte des périodes sans activités.

Le nombre de batchs en machine a fluctué entre 80 et 180 - mais n'oublions pas que l'expérience n'a qu'un quota équivalent à 200 batchs...

Le nombre d'opérations par jour - c'est-à-dire le nombre d'images sauvées et vérifiées - à varier entre 40.000 et 120.000, pour une moyenne d'environ 80.000. Cela représente l'équivalent de 12 à 15 MB/s en moyenne par heure d'activité. Mais il convient de préciser que chaque image commençait par être lue depuis le disque SPS afin de calculer ces clés MD5 - utilisée traditionnellement dans la base de données ErosDb - et SHA256, utilisée par Irods, que l'image était copiée dans Irods, et que l'image copiée était relue afin de s'assurer de la validité des clés calculées sur l'image source.

Par ailleurs, Jean-Baptiste a transféré à Lyon les clés MD5 calculées pour les images sur son système, ce qui permet de s'assurer 1) que le nombre d'images sauvées correspond au nombre d'images recopiées par Jean-Baptiste; et 2) que les clés MD5 sont conformes à toutes les étapes du transfert.

Le premier diagramme montre le passage des batchs et le nombre d'opérations réalisées par jour. Les deux périodes sans activité correspondent l'une à une erreur de stratégie : j'attendais la fin des transferts avant de commencer la recopie, ce qui n'a pas de sens; et la seconde à la nécessité de libérer de l'espace sur le disque, le programme CG ayant saturé les quelques TB du disque SPS.

Le deuxième diagramme montre les jours d'activités, en ignorant les "temps morts". Le diagramme montre que le nombre d'opérations suit plus ou moins le nombre de batchs, même s'il y a quelques fluctuations.

Le troisième montre le taux des transferts, en MB/s, ce qui, compte tenu des conditions et des doubles vérifications effectuées sur les images, est plutôt bon.