| 6 | | |
| 7 | | * Possibilité de garder les fichiers p86ipsl sur la partie lustre du storedir |
| 8 | | * Il y aura une plus grande marge de manoeuvre pour le posttraitement sur le nouveau calculateur |
| 9 | | * Le TGCC demande à avoir la main sur le même bench que celui de l'IDRIS. Dimitri Lecas est en train de rajouter des commandes times dans le bench pour mieux évaluer le temps passé dans chaque partie |
| 10 | | |
| 11 | | * Possibilité de paramétrer les fichiers devant rester sur le lustre sans copie sur bande en fonction du nom du fichier ou du répertoire (utilisable pour la gestion des fichiers dans la chaine sur SX9 et Titane) |
| 12 | | * Possibilité de création d'un espace tampon supplémentaire pour facilité le déménagement. Cet espace regrouperait les 4PB encore non utilisés (lustre + cccworkdir). |
| 13 | | * Le déménagement se fera par dmnfs – un dmnfs est stocké entièrement sur les mêmes bandes. |
| 14 | | * Il n'y aura plus d'administrateur cesium à partir de septembre 2012 |
| 15 | | * Discussion sur les workflow / question du demon par login ou groupe / question des crontab / python / actuellement installation de unicorn sur le centre de calcul |
| 16 | | * Faire attention pour le déménagement de prendre la bonne version de netcdf |
| 17 | | * Problème du bug ncrcat/netcdf -> comment éviter ce genre de bug à l'avenir ? Pour les admin problème de connaissance des logiciels installés sur les centres. Il faut donc continuer la veille |
| 18 | | * Quel niveau de certitude veut-on pour la fiabilité du déménagement ? |
| 19 | | * Machine déménagement : à l'origine deux noeuds spécifiques y été dédié, mais cela serait compliqué de les transformer en noeuds de calcul. --> le déménagement sera donc intégré directement sur une machine (Curie certainement) |
| 20 | | * Actuellement 8 lecteurs de bandes + 4 obsolètes. Vraisemblablement 2 ou 3 lecteurs seront dédiés au déménagement |
| 21 | | * Temps pour décharger une bande ? Ne savent pas |
| 22 | | * 1 bande = 500 G ou 1T en fonction des bandes. En format compressé. |
| 23 | | * Possibilité de queue infinie pour le déménagement. /!\ Attention aux pannes machines. Il faut donc gérer la relance du job de pack |
| 24 | | * possibilité de souplesse sur les petits fichiers. Il faut trouver un compromis |
| 25 | | * Titane s'arrête mi 2013 |
| 26 | | * Discussion sur les tests --> cela implique beaucoup de petits fichiers à conserver. Il faut peut être utiliser la partie lustre sans copie sur bande |
| 27 | | * Gestion des bandes cassées ???? pas clair cette histoire |
| 28 | | * Question de la double copie : à faire au moment du pack /// il faut l'accord genci |
| 29 | | |
| 30 | | PACK |
| 31 | | * On enlève l'étape de check préalable (sans toucher les fichiers) pour l'inclure dans le pack après déportation des fichiers sur l'espace tampon |
| 32 | | * Avant déménagement chaque utilisateur doit décider si sa simul sera |
| 33 | | * tar par défaut |
| 34 | | * tar ccc_archive |
| 35 | | * pack : (si l'on veut continuer cette simul ou encore exploiter ses sorties) |
| 36 | | * missing value |
| 37 | | * tar (pour redo ultérieur) |
| 38 | | * Le pack se fera d'un seul tenant sans intervention humaine en cours |
| 39 | | * Tous les comptes seront déménagés même les utilisateurs ne travaillant plus au ccrt |
| 40 | | * Si on n'arrive pas à packer on réessaie une fois et sinon on tar |
| 41 | | * Question : que faire des fichiers pour lesquels le pack et le tar ne fonctionne pas (cas très peu probable) ? |
| 42 | | * On les laisse sur l'espace tampon et chaque utilisateur fait son ménage |
| | 6 | * Points importants, des discussions du dernier jour: |
| | 7 | * Possibilité de garder les fichiers p86ipsl sur la partie lustre du storedir. |
| | 8 | * Il y aura une plus grande marge de manoeuvre pour le post-traitement sur le nouveau calculateur Curie. |
| | 9 | * Le TGCC demande à avoir la main sur le même bench que celui de l'IDRIS. Dimitri Lecas est en train de rajouter des commandes times dans le bench pour mieux évaluer le temps passé dans chaque partie |
| | 10 | * Possibilité de paramétrer les fichiers devant rester sur le lustre sans copie sur bande en fonction du nom du fichier ou du répertoire (utilisable pour la gestion des fichiers dans la chaine sur SX9 et Titane) |
| | 11 | * Possibilité de création d'un espace tampon supplémentaire pour facilité le déménagement. Cet espace regrouperait les 4PB encore non utilisés (lustre + cccworkdir). |
| | 12 | * Le déménagement se fera par dmnfs – un dmnfs est stocké entièrement sur les mêmes bandes. |
| | 13 | * Tous les comptes seront déménagés même les utilisateurs ne travaillant plus au ccrt |
| | 14 | * Il n'y aura plus d'administrateur cesium à partir de septembre 2012 |
| | 15 | * Discussion sur les workflow / question du demon par login ou groupe / question des crontab / python / actuellement installation de unicore sur le centre de calcul |
| | 16 | * Faire attention pour le déménagement de prendre la bonne version de netcdf |
| | 17 | * Problème du bug ncrcat/netcdf -> comment éviter ce genre de bug à l'avenir ? Pour les admin il y a un problème de connaissance des logiciels installés sur les centres. Il faut donc continuer la veille |
| | 18 | * Quel niveau de certitude veut-on pour la fiabilité du déménagement ? |
| | 19 | * Machine déménagement : le déménagement sera donc intégré directement sur une machine (Curie certainement) |
| | 20 | * Actuellement 8 lecteurs de bandes + 4 obsolètes. Vraisemblablement 2 ou 3 lecteurs seront dédiés au déménagement |
| | 21 | * Temps pour décharger une bande ? Ne savent pas |
| | 22 | * 1 bande = 500 G ou 1T en fonction des bandes. En format compressé. |
| | 23 | * Possibilité de queue infinie (semaine(s)) pour le déménagement. /!\ Attention aux pannes machines. Il faut donc gérer la relance du job de pack |
| | 24 | * Possibilité de souplesse sur les petits fichiers. Il faut trouver un compromis. |
| | 25 | * Titane s'arrête mi 2013 |
| | 26 | * Discussion sur les tests --> cela implique beaucoup de petits fichiers à conserver. Il faut peut être utiliser la partie lustre sans copie sur bande. |
| | 27 | * Gestion des bandes cassées ???? Au cas pas cas, pas clair pour l'instant. |
| | 28 | * Question de la double copie : à faire au moment du pack /// il faut l'accord genci |
| | 29 | * PACK |
| | 30 | * Avant déménagement chaque utilisateur doit décider si ses simulations seront: |
| | 31 | * "tarer" par défaut |
| | 32 | * "tarer" selon la géométrie ccc_archive |
| | 33 | * "packer" (si l'on veut continuer cette simulation ou encore exploiter les sorties) |
| | 34 | * s'il y a des "trous" dans la simulation : remplissage avec des missing value |
| | 35 | * s'il y a des "trous" dans la simulation : tar (pour "redo" ultérieur) |
| | 36 | * Le pack se fera d'un seul tenant sans intervention humaine en cours |
| | 37 | * Si on n'arrive pas à packer on réessaie une fois et sinon on tar |
| | 38 | * Question : que faire des fichiers pour lesquels le pack et le tar ne fonctionne pas (cas très peu probable) ? |
| | 39 | * On les laisse sur l'espace tampon et chaque utilisateur fait son ménage |
