synthèse sur les storagepools BeeGFS :

• toute donnée copiée ou nouvellement créée appartient au storagepool de son dossier parent
• toute donnée déplacée (mv) reste dans son storagepool, quelque soit l’appartenance de son dossier parent => c’est le comportement de BeeGFS v7, pas modifiable
• pour changer le storagepool d’une donnée déplacée, il faut lui appliquer en plus une opération de migration
• Exemple pour migrer une donnée du pool 2 que tu as déplacé dans ton home :

# toute donnee de <dossier> qui est dans le pool 2 va dans le pool 1
> beegfs-ctl --migrate --storagepoolid=2 --destinationpoolid=1 <dossier>

• cette opération de migration peut être effectuée par n’importe quel utilisateur sur ses données
• nous ne faisons de migration automatique que sur archives, dans le sens « toute donnée du pool 1 va dans le pool 2 »
• cette migration sur archives est programmée une fois par semaine, dans la nuit de samedi à dimanche
• une migration automatisée, comme celle sur archives, a un coût important car elle vient balayer toutes les données du dossier principal
• nous ne faisons pas de migration automatisée « reverse » (ie migrer toute donnée des homes dans le pool 2 vers le pool 1) pour 2 raisons :
  • nous avons considéré qu’une donnée froide reste froide
  • faire un balayage régulier des données du pool chaud revient à solliciter quasi inutilement les disques SSD du pool chaud, qui ont un TTL (durée de vie) programmée dès l’achat
• il faut donc éviter de faire trop d’allers-retours entre son home et son dossier archives
• pour avoir la constitution des storagepools, tu peux utiliser la commande suivante :

> beegfs-ctl --liststoragepools
Pool ID   Pool Description                      Targets                 Buddy Groups
======= ================== ============================ ============================
      1            Default 1,2                                                      
      2              Froid 3,4 

 
cette commande indique que les « storage targets » 1 et 2 appartiennent au storagepool 1 (pool chaud ou Default) et que les storagepools 3 et 4 appartiennent au storagepool 2 (pool froid)

• pour savoir à quel storagepool appartient une donnée, il faut utiliser la commande suivante :

$ beegfs-ctl –getentryinfo OpenMP/exo7.f90EntryID: D-5AE1CC38-1Metadata node: beegfs01-osaka [ID: 1]Stripe pattern details:+ Type: RAID0+ Chunksize: 1M+ Number of storage targets: desired: 2; actual: 2+ Storage targets:  + 2 @ beegfs01-osaka [ID: 1]  + 1 @ beegfs01-osaka [ID: 1]
On voit qu’ici, la donnée appartient au storagepool [ID: 1] (pool chaud) et qu’elle est distribuée sur les storage target 1 et 2 (normal)

Après, pour revenir à ton problème de fichiers non écrits, il y a plusieurs explications possibles :

• déjà, au niveau configuration des storagepools, elles se ressemblent, donc il n’y a pas de raison pour que des données puissent être produites dans un storagepool et pas dans l’autre
• problème de quota sur ton compte dans le pool 2
• exécution du job sur un noeud ayant posé problème dernièrement (typiquement le noeud 52 ou 54)
• si tu as le jobId du job en question, on peut essayer de regarder