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