2.7. Attribution de blocs

Lorsqu'un système de fichiers GFS2 est presque plein, l'allocateur de blocs commence à avoir du mal à trouver de l'espace pour les nouveaux blocs à allouer. Par conséquent, les blocs alloués par l'allocateur ont tendance à se retrouver à la fin d'un groupe de ressources ou dans de minuscules tranches où la fragmentation des fichiers est beaucoup plus probable. Cette fragmentation des fichiers peut entraîner des problèmes de performance. En outre, lorsqu'un système de fichiers GFS2 est presque plein, l'allocateur de blocs GFS2 passe plus de temps à rechercher dans plusieurs groupes de ressources, ce qui ajoute une contention de verrouillage qui n'existerait pas nécessairement sur un système de fichiers disposant de beaucoup d'espace libre. Cela peut également entraîner des problèmes de performance.

Pour ces raisons, il est recommandé de ne pas utiliser un système de fichiers rempli à plus de 85 %, bien que ce chiffre puisse varier en fonction de la charge de travail.

Lorsque vous développez des applications destinées à être utilisées avec les systèmes de fichiers GFS2, il est recommandé que chaque nœud alloue ses propres fichiers, si possible. En raison du fonctionnement du gestionnaire de verrous distribués (DLM), il y aura plus de conflits de verrous si tous les fichiers sont alloués par un nœud et que d'autres nœuds ont besoin d'ajouter des blocs à ces fichiers.

Le terme "maître des verrous" a été utilisé historiquement pour désigner un nœud qui est actuellement le coordinateur des demandes de verrous, qui proviennent d'un nœud local ou d'un nœud distant dans le cluster. Ce terme de coordinateur des demandes de verrouillage est légèrement trompeur, car il s'agit en réalité d'une ressource (dans la terminologie DLM) par rapport à laquelle les demandes de verrouillage sont soit mises en file d'attente, soit accordées, soit refusées. Dans le sens où ce terme est utilisé dans le DLM, il doit être considéré comme faisant référence au "premier parmi les égaux", puisque le DLM est un système pair-à-pair.

Dans la mise en œuvre du DLM du noyau Linux, le nœud sur lequel le verrou est utilisé pour la première fois devient le coordinateur des demandes de verrou, et ne change plus ensuite. Il s'agit d'un détail d'implémentation du DLM du noyau Linux et non d'une propriété des DLM en général. Il est possible qu'une future mise à jour permette à la coordination des demandes de verrouillage pour un verrou particulier de passer d'un nœud à l'autre.

L'endroit où les demandes de verrouillage sont coordonnées est transparent pour l'initiateur de la demande de verrouillage, sauf en ce qui concerne l'effet sur la latence de la demande. L'une des conséquences de la mise en œuvre actuelle est qu'en cas de déséquilibre de la charge de travail initiale (par exemple, un nœud parcourt l'ensemble du système de fichiers avant que d'autres n'exécutent des commandes d'E/S), il peut en résulter des temps de latence de verrouillage plus élevés pour les autres nœuds de la grappe que pour le nœud qui a effectué le premier balayage du système de fichiers.

Comme dans de nombreux systèmes de fichiers, l'allocateur GFS2 tente de maintenir les blocs d'un même fichier à proximité les uns des autres afin de réduire le déplacement des têtes de disque et d'améliorer les performances. Un nœud qui alloue des blocs à un fichier devra probablement utiliser et verrouiller les mêmes groupes de ressources pour les nouveaux blocs (à moins que tous les blocs de ce groupe de ressources ne soient utilisés). Le système de fichiers fonctionnera plus rapidement si le coordinateur des demandes de verrouillage pour le groupe de ressources contenant le fichier alloue ses blocs de données (il est plus rapide de demander au nœud qui a ouvert le fichier en premier d'écrire tous les nouveaux blocs).

Si les fichiers sont préalloués, l'allocation de blocs peut être évitée et le système de fichiers peut fonctionner plus efficacement. GFS2 inclut l'appel système fallocate(1), que vous pouvez utiliser pour préallouer des blocs de données.