Hola a todos!

Me hago eco aquí de un artículo de Microsoft que está únicamente en inglés y que he usado como apoyo para un artículo que he escrito para otro blog y que me parece interesante tener al alcance de aquéllos que no aman la lengua de Shakespeare.

Los sistemas de archivos de Microsoft organizan los dispositivos de almacenamiento según el tamaño del clúster.

También conocido como el tamaño de la unidad de asignación, el tamaño del clúster representa la cantidad más pequeña de espacio en disco que se puede asignar para contener un archivo.

Debido a que ReFS y NTFS no hacen referencia a los archivos con una granularidad de bytes, el tamaño del clúster es la unidad de tamaño más pequeña a la que cada sistema de archivos puede hacer referencia al acceder al almacenamiento.

Tanto ReFS como NTFS admiten varios tamaños de clúster, ya que los clústeres de diferentes tamaños pueden ofrecer diferentes beneficios de rendimiento, según la implementación.

En las últimas dos semanas, hemos visto cierta confusión con respecto a los tamaños de clúster recomendados para ReFS y NTFS, por lo que esperamos que este blog elimine la ambigüedad de las recomendaciones anteriores y ayude a proporcionar el razonamiento detrás de por qué se recomiendan algunos tamaños de clúster para ciertos escenarios.

Amplificación IO

Antes de saltar a las recomendaciones de tamaño de clúster, será importante comprender qué es la amplificación de IO y por qué es importante minimizar la amplificación de IO al elegir los tamaños de clúster:

• La amplificación de E/S se refiere al amplio conjunto de circunstancias en las que una operación de E/S desencadena otras operaciones de E/S no intencionales.
• Aunque puede parecer que solo se produjo una operación de E/S, en realidad, el sistema de archivos tuvo que realizar varias operaciones de E/S para atender con éxito la E/S inicial.
• Este fenómeno puede ser especialmente costoso si se consideran las diversas optimizaciones que el sistema de archivos ya no puede realizar:

• Al realizar una escritura, el sistema de archivos podría realizar esta escritura en la memoria y vaciar esta escritura en el almacenamiento físico cuando corresponda.
• Esto ayuda a acelerar drásticamente las operaciones de escritura al evitar el acceso a medios lentos y no volátiles antes de completar cada escritura.

• Ciertas escrituras, sin embargo, podrían obligar al sistema de archivos a realizar operaciones de E/S adicionales, como leer datos que ya están escritos en un dispositivo de almacenamiento.
• La lectura de datos de un dispositivo de almacenamiento retrasa significativamente la finalización de la escritura original, ya que el sistema de archivos debe esperar hasta que se recuperen los datos apropiados del almacenamiento antes de realizar la escritura.

Tamaños de clúster de ReFS

ReFS ofrece clústeres de 4K y 64K. 4K es el tamaño de clúster predeterminado para ReFS y recomendamos usar tamaños de clúster de 4K para la mayoría de las implementaciones de ReFS porque ayuda a reducir la costosa amplificación de E/S:

• En general, si el tamaño del clúster excede el tamaño del IO, ciertos flujos de trabajo pueden desencadenar que ocurran IO no deseados.
• Considere los siguientes escenarios en los que se formatea un volumen ReFS con clústeres de 64 000:

• Considere un volumen en niveles. Si se realiza una escritura de 4K en un rango que actualmente se encuentra en el nivel de capacidad, ReFS debe leer todo el clúster desde el nivel de capacidad hasta el nivel de rendimiento antes de realizar la escritura.
• Debido a que el tamaño del clúster es la granularidad más pequeña que puede usar el sistema de archivos, ReFS debe leer todo el clúster, que incluye una región de 60K sin modificar, para poder completar la escritura de 4K.

• Si varias regiones comparten un clúster después de que se produce una operación de clonación de bloques, ReFS debe copiar todo el clúster para mantener el aislamiento entre las dos regiones.
• Entonces, si se realiza una escritura de 4K en este clúster compartido, ReFS debe copiar el clúster de 60K sin modificar antes de realizar la escritura.

• Considere una implementación que permita flujos de integridad.
• Una escritura de granularidad de subclúster hará que todo el clúster se vuelva a asignar y se vuelva a escribir, y se debe calcular la nueva suma de verificación.
• Esto representa una E/S adicional que ReFS debe realizar antes de completar la nueva escritura, lo que introduce un factor de latencia mayor en la operación de E/S.

• Al elegir clústeres de 4K en lugar de clústeres de 64K, se puede reducir la cantidad de IO que son más pequeñas que el tamaño del clúster, lo que evita que las costosas amplificaciones de IO ocurran con tanta frecuencia.

Además, los tamaños de clúster de 4K ofrecen una mayor compatibilidad con la granularidad de E/S de Hyper-V, por lo que recomendamos usar tamaños de clúster de 4K con Hyper-V en ReFS.

Los clústeres de 64 000 son aplicables cuando se trabaja con E/S secuencial grande, pero de lo contrario, 4 000 debería ser el tamaño de clúster predeterminado.

Tamaños de clúster NTFS

NTFS ofrece tamaños de clúster de 512 a 64 K, pero, en general, recomendamos un tamaño de clúster de 4 K en NTFS, ya que los clústeres de 4 K ayudan a minimizar el espacio desperdiciado al almacenar archivos pequeños.

También desaconsejamos encarecidamente el uso de tamaños de clúster inferiores a 4K. Sin embargo, hay dos casos en los que los clústeres de 64 000 podrían ser apropiados:

• Los clústeres de 4K limitan el volumen máximo y el tamaño de archivo a 16 TB

• Los tamaños de clúster de 64 000 pueden ofrecer un mayor volumen y capacidad de archivo, lo cual es relevante si aloja una gran implementación en su volumen NTFS, como el alojamiento de VHD o una implementación de SQL.

• NTFS tiene un límite de fragmentación y los tamaños de clúster más grandes pueden ayudar a reducir la probabilidad de alcanzar este límite

• Debido a que NTFS es compatible con versiones anteriores, debe usar estructuras internas que no fueron optimizadas para las demandas de almacenamiento modernas.
• Por lo tanto, los metadatos en NTFS evitan que cualquier archivo tenga más de ~1,5 millones de extensiones.

• Sin embargo, se puede utilizar la opción «formato /L» para aumentar el límite de fragmentación a ~6 millones. Leer más aquí.

• Las implementaciones de clústeres de 64 000 son menos susceptibles a este límite de fragmentación, por lo que los clústeres de 64 000 son una mejor opción si el límite de fragmentación de NTFS es un problema.
• La deduplicación de datos, los archivos dispersos y las implementaciones de SQL pueden causar un alto grado de fragmentación.

• Desafortunadamente, la compresión NTFS solo funciona con clústeres de 4K, por lo que el uso de clústeres de 64K no es adecuado cuando se utiliza la compresión NTFS. Considere aumentar el límite de fragmentación en su lugar, como se describe en las viñetas anteriores.

Si bien un tamaño de clúster de 4K es la configuración predeterminada para NTFS, hay muchos escenarios en los que los tamaños de clúster de 64K tienen sentido, como: Hyper-V, SQL, deduplicación o cuando la mayoría de los archivos en un volumen son grandes.

El artículo original:

Cluster size recommendations for ReFS and NTFS – Microsoft Community Hub

Un saludo