1.3. Consideraciones sobre el formato de GFS2

Esta sección ofrece recomendaciones sobre cómo formatear su sistema de archivos GFS2 para optimizar el rendimiento.

Tamaño del sistema de archivos: Cuanto más pequeño, mejor

GFS2 se basa en una arquitectura de 64 bits, que teóricamente puede albergar un sistema de archivos de 8 EB. Sin embargo, el tamaño máximo admitido actualmente de un sistema de archivos GFS2 para el hardware de 64 bits es de 100 TB.

Tenga en cuenta que aunque los sistemas de archivos de gran tamaño de GFS2 son posibles, eso no significa que sean recomendables. La regla general con GFS2 es que más pequeño es mejor: es mejor tener 10 sistemas de archivos de 1TB que un sistema de archivos de 10TB.

Hay varias razones por las que deberías mantener tus sistemas de archivos GFS2 pequeños:

Además, un menor número de grupos de recursos que mantener supone un mayor rendimiento.

Por supuesto, si haces tu sistema de archivos GFS2 demasiado pequeño, podrías quedarte sin espacio, y eso tiene sus propias consecuencias. Debes considerar tus propios casos de uso antes de decidir el tamaño.

Tamaño del bloque: Se prefieren los bloques por defecto (4K)

El comando mkfs.gfs2 intenta estimar un tamaño de bloque óptimo basado en la topología del dispositivo. En general, los bloques de 4K son el tamaño de bloque preferido porque 4K es el tamaño de página (memoria) por defecto para Red Hat Enterprise Linux. A diferencia de otros sistemas de archivos, GFS2 realiza la mayoría de sus operaciones utilizando buffers de kernel de 4K. Si su tamaño de bloque es 4K, el kernel tiene que hacer menos trabajo para manipular los buffers.

Se recomienda utilizar el tamaño de bloque por defecto, que debería producir el mayor rendimiento. Puede que necesites utilizar un tamaño de bloque diferente sólo si necesitas un almacenamiento eficiente de muchos archivos muy pequeños.

Tamaño del diario: Por defecto (128MB) suele ser óptimo

Cuando se ejecuta el comando mkfs.gfs2 para crear un sistema de archivos GFS2, se puede especificar el tamaño de los diarios. Si no se especifica un tamaño, será por defecto de 128MB, que debería ser óptimo para la mayoría de las aplicaciones.

Algunos administradores de sistemas podrían pensar que 128MB es excesivo y estarían tentados a reducir el tamaño del diario al mínimo de 8MB o a un más conservador 32MB. Aunque esto podría funcionar, puede afectar gravemente al rendimiento. Al igual que muchos sistemas de archivos con registro en el diario, cada vez que GFS2 escribe metadatos, éstos se consignan en el diario antes de colocarlos. Esto asegura que si el sistema se bloquea o pierde energía, recuperará todos los metadatos cuando el diario se reproduzca automáticamente en el momento del montaje. Sin embargo, no hace falta mucha actividad del sistema de archivos para llenar un diario de 8 MB, y cuando el diario está lleno, el rendimiento se ralentiza porque GFS2 tiene que esperar las escrituras en el almacenamiento.

Generalmente se recomienda utilizar el tamaño de diario por defecto de 128MB. Si su sistema de archivos es muy pequeño (por ejemplo, 5GB), tener un diario de 128MB puede ser poco práctico. Si tienes un sistema de archivos más grande y puedes permitirte el espacio, usar diarios de 256MB podría mejorar el rendimiento.

Tamaño y número de grupos de recursos

Cuando se crea un sistema de archivos GFS2 con el comando mkfs.gfs2, éste divide el almacenamiento en porciones uniformes conocidas como grupos de recursos. Intenta estimar un tamaño de grupo de recursos óptimo (que va de 32MB a 2GB). Puede anular el valor predeterminado con la opción -r del comando mkfs.gfs2.

El tamaño óptimo de su grupo de recursos depende de cómo vaya a utilizar el sistema de archivos. Ten en cuenta lo lleno que estará y si estará o no muy fragmentado.

Debería experimentar con diferentes tamaños de grupos de recursos para ver cuál resulta en un rendimiento óptimo. Es una buena práctica experimentar con un clúster de prueba antes de desplegar GFS2 en plena producción.

Si tu sistema de archivos tiene demasiados grupos de recursos, cada uno de los cuales es demasiado pequeño, las asignaciones de bloques pueden perder demasiado tiempo buscando decenas de miles de grupos de recursos para un bloque libre. Cuanto más lleno esté tu sistema de archivos, más grupos de recursos se buscarán, y cada uno de ellos requiere un bloqueo en todo el clúster. Esto conduce a un rendimiento lento.

Sin embargo, si su sistema de archivos tiene muy pocos grupos de recursos, cada uno de los cuales es demasiado grande, las asignaciones de bloques pueden competir más a menudo por el mismo bloqueo de grupo de recursos, lo que también afecta al rendimiento. Por ejemplo, si tiene un sistema de archivos de 10 GB que está dividido en cinco grupos de recursos de 2 GB, los nodos de su clúster se pelearán por esos cinco grupos de recursos con más frecuencia que si el mismo sistema de archivos estuviera dividido en 320 grupos de recursos de 32 MB. El problema se agrava si el sistema de archivos está casi lleno, ya que cada asignación de bloques podría tener que buscar en varios grupos de recursos antes de encontrar uno con un bloque libre. GFS2 intenta mitigar este problema de dos maneras:

El peor escenario es cuando hay un directorio central en el que todos los nodos crean archivos, porque todos los nodos lucharán constantemente para bloquear el mismo grupo de recursos.