Seguridad de la caché de escritura en unidades SATA con barreras

Últimamente he estado leyendo sobre el almacenamiento en caché de escritura, NCQ, errores de firmware, barreras, etc. con respecto a las unidades SATA, y no estoy seguro de cuál es la mejor configuración que haría que mis datos estén seguros en caso de una falla de energía.

Por lo que entiendo, NCQ permite que la unidad reordene las escrituras para optimizar el rendimiento, al tiempo que mantiene informado al núcleo sobre las solicitudes que se han escrito físicamente.

La caché de escritura hace que la unidad atienda una solicitud mucho más rápido, porque no espera a que los datos se escriban en el disco físico.

No estoy seguro de cómo se mezclan NCQ y Write cache aquí ...

Los sistemas de archivos, especialmente los que tienen un diario, deben estar seguros cuando se ha escrito una solicitud en particular. Además, el proceso de espacio de usuario usa fsync () para forzar el vaciado de un archivo en particular. Esa llamada a fsync () no debería volver hasta que el sistema de archivos esté seguro de que los datos se escriben en el disco.

Hay una característica (FUA, Force Unit Access), que solo he visto en unidades SAS, que obliga a la unidad a omitir la memoria caché y escribir directamente en el disco. Para todo lo demás, hay barreras de escritura, que es un mecanismo proporcionado por el núcleo que puede desencadenar un vaciado de caché en la unidad. Esto obliga a que se escriba todo el caché, no solo los datos críticos, lo que ralentiza todo el sistema si se abusa, con fsync (), por ejemplo.

Y luego hay unidades con errores de firmware, o que mienten deliberadamente sobre cuándo se han escrito físicamente los datos.

Dicho esto ... hay varias formas de configurar las unidades / sistemas de archivos: A) NCQ y caché de escritura deshabilitado B) Solo NCQ habilitado C) Simplemente escribir caché habilitado D) Tanto NCQ como caché de escritura habilitado

Asumo que las barreras están habilitadas. Por cierto, ¿cómo verificar si realmente están habilitadas?

En caso de pérdida de energía, mientras escribo activamente en el disco, supongo que la opción B (NCQ, sin caché) es segura, tanto para el diario del sistema de archivos como para los datos. Puede haber una penalización de rendimiento.

La opción D (NCQ + caché), si usa barreras o FUA, sería segura para el diario del sistema de archivos y las aplicaciones que usan fsync (). Sería malo para los datos que esperaban en el caché, y depende del sistema de archivos detectarlo (suma de verificación), y al menos el sistema de archivos no estará (con suerte) en un estado inestable. En cuanto al rendimiento, debería ser mejor.

Mi pregunta, sin embargo, se mantiene ... ¿Me estoy perdiendo algo? ¿Hay alguna otra variable a tener en cuenta? ¿Hay alguna herramienta que pueda confirmar esto y que mis unidades se comporten como deberían?

Para los sistemas Enterprise directos, hay una capa adicional en forma de adaptador de almacenamiento (casi siempre una tarjeta RAID) en la que existe otra capa de caché. Hay una gran cantidad de abstracción en la pila de almacenamiento en estos días, y entré en detalles profundos en esto en una serie de blogs que hice en la conoce a su E / S .

Las tarjetas RAID pueden omitir la memoria caché en el disco, algunas de las cuales incluso permiten alternar esta función en el BIOS RAID. Esta es una razón por la cual los discos Enterprise son Enterprise, su firmware permite cosas que las unidades de consumo ( especialmente las unidades 'verdes') no lo hacen. Esta característica aborda directamente el caso que le preocupa: falla de energía con escrituras no comprometidas. La memoria caché de la tarjeta RAID, que debe estar respaldada por batería o flash, se conservará hasta que vuelva la energía y esas escrituras se puedan volver a activar.

Ciertos SSD empresariales incluyen un condensador integrado con suficiente empuje para confirmar la memoria caché integrada antes de apagarse por completo.

Si está trabajando con un sistema con discos directamente conectados a la placa base, hay menos garantías. A menos que los discos mismos tengan la capacidad de comprometer la memoria caché de escritura, una falla de energía causará una pérdida. El sistema de archivos xfs se ganó la reputación de no ser confiable debido a su incapacidad para sobrevivir solo en este modo de falla; Fue diseñado para ejecutarse en sistemas empresariales completos con capacidad de supervivencia de almacenamiento de ingeniería.

Sin embargo, el tiempo avanzó y XFS se diseñó para sobrevivir. Los otros sistemas de archivos Linux principales (así como ntfs en Windows) ya tenían ingeniería para sobrevivir a este modo de falla. Cómo se supone que debe funcionar es que las escrituras perdidas no aparecerán en el diario FS y sabrá que no se comprometieron, por lo que la corrupción se detectará y evitará de forma segura.

Usted señala el único problema aquí: el firmware del disco que se encuentra. En este caso, la revista FS habrá hecho una suposición errónea frente a la realidad y es posible que la corrupción no se detecte durante algún tiempo. RAID de paridad y RAID espejo pueden solucionar esto, ya que debería haber otra copia comprometida para extraer. Pero las configuraciones de disco único no tendrán esa verificación cruzada, por lo que en realidad fallará.

Para evitar el riesgo de firmware, utilice unidades de grado empresarial que obtienen mucha más validación (y se prueban en comparación con sus patrones de carga de trabajo presuntos), y diseñando su sistema de almacenamiento para que pueda sobrevivir a tales falsedades.

El diario del sistema de archivos originalmente esperó a que se completara la escritura en el diario antes de emitir la escritura en los metadatos, suponiendo que no había caché de escritura de unidad. Con el almacenamiento en caché de escritura de unidad habilitado, esta suposición se rompe y puede causar la pérdida de datos. Por lo tanto, se crearon barreras. Con barreras, el diario puede asegurarse de que la escritura en el diario se complete antes de la escritura en los metadatos, incluso si el disco está usando el almacenamiento en caché de escritura. En la capa del controlador de disco, la barrera fuerza el vaciado de la memoria caché del disco antes de que se envíe IO posterior, cuando la unidad informa que tiene una memoria caché de escritura y está habilitada. De lo contrario, esto no es necesario, por lo que la barrera solo evita la emisión del IO posterior al variador hasta que el IO anterior se haya completado. NCQ solo significa que podría tener que esperar a que se complete más de una solicitud pendiente antes de emitir más.