Los discos desde la perspectiva de un Sistema de Archivos

Esta es mi propia traducción e interpretación del artículo Disks from the Perspective of a File System escrito por Marshall Kirk McKusick¹ para ACMQ.

Los Discos mienten. Y los controladores que los corren son cómplices del crimen. Link to heading

La mayoría de las aplicaciones no tienen que negociar con los discos directamente, sino que guardan sus datos en archivos dentro del sistema de archivos, el cual nos protege de los discos sinvergüenzas. Después de todo, la tarea principal del sistema de archivos es asegurarse a sí mismo que siempre pueda ser recuperado a un estado consistente después de una caída del sistema no planeada (por ejemplo, una falla de energía). Mientras que un buen sistema de archivos sea capaz de mantener a los discos bajo control, el esfuerzo requerido puede ser mucho y el rendimiento reducido es molesto. Este artículo examina los atajos que toman los discos y las vueltas que los sistemas de archivos tienen que dar para tener la confiabilidad deseada.

Mientras que el sistema de archivos deba recuperarse en un estado consistente, ese estado usualmente refleja como estaba el sistema de archivos un tiempo antes de la caída. A menudo los datos escritos durante el minuto antes de la caída pudieron haberse perdido. La razón de esta perdida es que el sistema de archivos es que todavía no tuvo la oportunidad de escribir esos datos a disco. Cuando una aplicación necesita asegurarse que los datos pueden recuperarse después de la caída, ejecuta una llamada al sistema fsync sobre el archivo que contiene los datos que necesitan para una estabilidad de largo plazo. Antes de regresar de la llamada al sistema fsync, el sistema de archivos debe de asegurarse que todos los datos asociados al archivo deben de recuperarse después de la caída, incluso si la caída ocurre inmediatamente después del regreso de la llamada del sistema fsync.

El sistema de archivos implementa fsync encontrando los datos sucios (no escritos) del archivo y escribiéndolos a disco. Históricamente, el sistema de archivos levantaría un requerimiento de escritura al disco de los datos sucios del archivo y esperar por la notificación de terminación de esta tarea. Esta técnica funcionaba de manera confiable hasta la llegada del cache de tareas en los controladores de disco. Los controladores con cache de tareas tienen un buffer grande en el mismo controlador que acumula los datos que serán escritos en el disco. Para evitar perder una revolución para ubicar el inicio del siguiente bloque al escribir en bloques de disco contiguos, el controlador lanza una notificación de escritura completada cuando los datos se encuentran en la cache de tareas en vez de encontrarse en el disco. Esta notificación de completado de escritura temprano es hecho con la esperanza de que el sistema pedirá una escritura para el siguiente bloque del disco a tiempo para que el controlador sea capaz de escribir inmediatamente al final del bloque previo.

Este enfoque tiene un serio efecto negativo. Cuando se entrega la notificación de escritura completada, el sistema de archivos espera que los datos estén almacenados de manera estable. Si los datos solo se encuentran en el cache de tareas y no en el disco, el sistema de archivos puede fallar al mantener la integridad deseada a las aplicaciones de usuario usando la llamada del sistema fsync. En particular, la semántica será violada si la energía falla después de la notificación de escritura pero antes de que los datos estén escritos en el disco. Algunos fabricantes eliminan este problema usando memoria no volátil para el cache de tareas y que provee un reinicio de micro-código después de la falla de energía donde las operaciones necesitan ser completadas. Debido a que esta opción es cara, solo algunos controladores proveen de esta funcionalidad.

Los discos más nuevos resuelven este problema con una técnica llamada tag queueing, en donde cada petición pasada al controlador de disco es asignada a una etiqueta numérica única. La mayoría de las controladoras que soportan tag queueing aceptan al menos 16 peticiones de I/O. Después de que cada petición es finalizada (posiblemente en un orden diferente al que llegaron al disco) la etiqueta de la petición completada es regresada como parte de la notificación de escritura. Si varios bloques contiguos son presentados a la controladora de disco, puede empezar a trabajar con el siguiente bloque mientras que la notificación para la etiqueta del anterior es regresada. Por lo tanto, tag queueing permite que las aplicaciones estén notificadas de verdad cuando sus datos hayan llegado al almacenamiento estable sin incurrir en penalización de revoluciones de disco perdidas al escribir bloques contiguos. La llamada fsync de un archivo es implementada al enviar todos los bloques modificados del archivo al disco y después esperar hasta que las etiquetas de todos esos bloques hayan notificado que está escrito.

Tag queueing fue implementado primero en discos SCSI, habilitándolos en confiabilidad y velocidad. Los discos ATA, que carecían de tag queueing, puede ser ejecutado con su cache de escritura activado (por defecto) para proveer de velocidad al costo de confiabilidad después de una caída o con el cache de escritura desactivado, que provee la confiabilidad después de una caída con un 50% de velocidad de escritura reducido.

Para salir del embrollo, la especificación ATA agregó un intento de tag queueing con el mismo nombre usado por la especificación SCSI: TCQ (Tag Command Queueing). Desafortunadamente en una desviación de la especificación SCSI, TCQ para ATA permite el completado de la petición etiquetada para depender de si el cache de escritura está activado (notificando que la tarea de escritura está completada cuando llega al cache) o desactivado (notificando que la tarea de escritura está completada cuando llega al medio). Por lo tanto, solo agregó complejidad sin beneficio alguno.

Por suerte, SATA (Serial ATA) tiene una nueva definición llamada NCQ (Native Command Queueing) que tiene un bit en el comando de escritura que indica al controlador si debe reportar que ha terminado cuando el medio ha sido escrito o cuando ha llegado a cache. Si el controlador ajusta el bit correctamente, entonces el disco tendrá un comportamiento correcto.

En el mundo real, muchos de los controladores enfocados para el mercado de escritorio no implementan la especificación NCQ. Para asegurar la confiabilidad, el sistema debe de desactivar el cache de escritura en disco o ejecutar un vaciado de cache después de cada actualización de meta-datos, actualización de bitácora (para sistemas de archivos con bitácora) o al ejecutar la llamada del sistema fsync. Ambas técnicas tienden a notar una degradación de rendimiento, así que frecuentemente están desactivadas, colocando al sistema de archivos en riesgo si la energía falla. En sistemas en donde la velocidad y confiabilidad son importantes, no se deben usar discos ATA. Se deben usar dispositivos que implementen Fibre Channel, SCSI o SATA que soporten NCQ.

Otra tendencia reciente ha sido el cambio del tamaño del sector en el disco. Desde la vez de la primera disponibilidad en la década de 1950 hasta 2010, el tamaño del sector en los discos ha sido de 512 bytes. En el 2010, los fabricantes de discos empezaron a producir discos con sectores de 4096 bytes.

Mientras la densidad de escrituras para discos ha sido incrementada con los años, el margen de error por bit ha aumentado, requiriendo el uso de códigos de corrección más largos. Los errores no están distribuidos uniformemente a través del disco. En realidad, un pequeño defecto causaría la pérdida de una cadena de bits. La mayoría de los sectores tienen algunos errores, pero un pequeño defecto puede causar que un simple sector necesite de corrección de muchos bits. Por lo tanto, el código de error debe tener suficiente redundancia por cada sector para manejar un alto radio de corrección incluso si la mayoría de los sectores no lo requieren. Al usar sectores más grandes hace posible amortizar el costo de los bits de corrección de errores extras sobre revisión de bits más larga. Usado sectores que son ocho veces más largos también elimina el 88% de las cabeceras de inicio y final de sector, reduciendo así el número de bits que no contienen datos en el disco. El efecto de red al pasar de los sectores de 512 bytes a los 4096 bytes está cerca de doblar la cantidad de datos de usuario que puede almacenarse en la tecnología de disco dada.

Al hacer I/O al disco, las peticiones de transferencia deben ser por múltiplos del tamaño de sector. Hasta el 2010, la unidad más pequeña para leer o escribir era de 512 bytes. Ahora la unidad más pequeña para leer o escribir en disco es de 4096 bytes.

Para compatibilidad con aplicaciones viejas, las controladoras de los discos nuevos con sectores de 4096 bytes emulan el sector de 512 bytes. Cuando se hace una escritura de 512 bytes, la controladora lee el sector de 4096 bytes conteniendo el área que será escrita en un buffer, reescribe los 512 bytes en el sector que será reemplazado, y después escribe el sector de 4096 bytes actualizado en el buffer al disco. Cuando corre en este modo, el disco se vuelve al menos 50% más lento por el modo de lectura y escritura requerido. Frecuentemente se vuelve más lento porque la controladora tiene que esperar cerca de una revolución del plato de disco antes de reescribir el sector que había leído.

Los sistemas de archivos deben de estar pendientes del cambio en los medios y asegurarse de que se adapten para siempre escribir en múltiplos del nuevo tamaño de sector. Históricamente, los sistemas de archivos eran organizados para almacenar archivos más pequeños que el sector de 512 bytes. Con el cambio en la tecnología de disco, la mayoría de los sistemas de archivos han evitado la lentitud de escritura en 512 bytes al hacer el tamaño de almacenamiento más pequeño en 4096 bytes. Por lo tanto, un archivo más pequeño que 512 bytes está colocado en un bloque de 4096 bytes. El resultado de este cambio es que toma hasta ocho veces más espacio de almacenamiento un sistema de archivos que predominantemente tiene archivos más pequeños. Ya que el tamaño del archivo promedio ha ido creciendo en años, para un sistema de archivos típico el cambio de tamaño de colocación mínimo de 4096 bytes ha resultado en un 10% a 15% de incremento de almacenamiento requerido.

Algunos sistemas de archivos han adaptado el cambio del tamaño del sector al colocar varios archivos pequeños en un solo sector de 4096 bytes. Para evitar la necesidad de hacer una operación de leer/modificar/escribir para actualizar un archivo pequeño, el sistema de archivos recolecta el cumulo de archivos pequeños que han cambiado recientemente y los escribe juntos en un nuevo sector de 4096 bytes. Cuando la mayoría de los archivos pequeños dentro de un sector han sido re-escritos en otro lugar, el sector es reclamado tomando los archivos pequeños remanentes dentro de este e incluirlos con otros nuevos archivos escritos en un nuevo sector. El sector vaciado puede ser usado en el futuro.

La conclusión es que los sistemas de archivos necesitan estar al pendiente de la tecnología de disco que están corriendo para asegurar que pueden manejar confiablemente la semántica que han prometido. Los usuarios deben de estar al pendiente de las limitaciones de las diferentes tecnologías de disco frente a los sistemas de archivos y seleccionar la tecnología que no resulte en un rendimiento pobre para el tipo de carga en el sistema de archivos que se manejará. A lo mejor, más adelante se debería de evitar el uso de discos mecánicos y cambiar a la tecnología de memoria flash, a no ser que, por supuesto, el almacenaje en flash empiece a usar los mismos trucos de bajo presupuesto.