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

13

Ú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?

julianjm
fuente
¿Cuál es la aplicación en tu situación? Estás pasando por alto el efecto o la influencia de un controlador RAID y su caché en la configuración. ¿En qué sistema operativo te estás enfocando también? ¿Qué sistema de archivos estás considerando?
ewwhite
No hay aplicación específica. He estado usando software raid1 durante años, pero nunca profundizo en el problema que representan las memorias caché de escritura. Además, haber examinado btrfs, para el que aún no existe un fsck confiable, me hace cuestionar qué puedo hacer para prevenir la corrupción, si la usara.
julianjm
1
Utilice ZFS en Linux en su lugar y combínelo con un dispositivo ZIL especialmente diseñado. Uso el DDRDrive para sistemas ZFS :)
ewwhite
¿Estás usando ZFS con FUSE?
julianjm
2
Asegúrese de obtener un UPS.
Michael Hampton

Respuestas:

11

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 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 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.

sysadmin1138
fuente
Entiendo que bajo RAID de hardware, depende del controlador hacer el almacenamiento en caché (con suerte con batería de respaldo), y es aconsejable tener la caché de discos real deshabilitada. En mi caso (no lo mencioné) estoy usando software raid. Parece que no se recomienda escribir caché, ya que provocará la pérdida de datos. Tal vez no sea catastrófico (corrupción del sistema de archivos), pero la pérdida de datos de todos modos. Me abstendré, por el momento, de migrar mi softraid1 + ext4 a btrfs + raid1. :)
julianjm
RAID no ayuda con esto, ya que los datos pueden ubicarse tan fácilmente en ambas unidades de memoria caché de escritura como una unidad.
psusi
@psusi No es una mitigación del 100%, pero proporciona protección adicional . Es un problema de tiempo. Las implementaciones RAID individuales difieren.
sysadmin1138
No es una mitigación en absoluto. La unidad secundaria no importa en absoluto, ya que en caso de un accidente, la primaria se copiará de nuevo sobre la secundaria para recuperarse. Por lo tanto, regresa a si la escritura llegó o no a la (primera) unidad o no.
psusi
3

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.

psusi
fuente
Creo que las barreras lo protegen de la corrupción del diario (si el sistema de archivos lo solicita), pero no estoy seguro acerca de los datos reales en los archivos ... Emitir una descarga de caché después de cada escritura haría que la caché de escritura fuera inútil, ¿no es así? ?
julianjm
@julianjm, por supuesto ... los datos del archivo en caché siempre se pierden en caso de un bloqueo, con o sin NCQ o cachés de escritura de unidades.
psusi