Errores de disco silenciosos y confiabilidad del intercambio de Linux

Según tengo entendido, los discos duros y los SSD implementan una corrección básica de errores dentro del disco, y la mayoría de las configuraciones RAID, por ejemplo, mdadm, dependerán de esto para decidir cuándo un disco no pudo corregir un error y debe desconectarse. Sin embargo, esto depende de que el almacenamiento sea 100% preciso en su diagnóstico de errores. Eso no es así, y una configuración común como un espejo RAID-1 de dos unidades será vulnerable: suponga que algunos bits de una unidad están corruptos y la unidad no informa un error de lectura. Por lo tanto, los sistemas de archivos como btrfs y ZFS implementan sus propias sumas de verificación, para no confiar en los firmwares de unidades defectuosas, cables SATA con fallas, etc.

Del mismo modo, la RAM también puede tener problemas de confiabilidad y, por lo tanto, tenemos RAM ECC para resolver este problema.

Mi pregunta es esta : ¿cuál es la forma canónica de proteger el archivo de intercambio de Linux de la corrupción silenciosa / podredumbre de bits no detectada por el firmware de la unidad en una configuración de dos discos (es decir, utilizando controladores de núcleo de línea principal)? Me parece que una configuración que carece de protección de extremo a extremo aquí (como la proporcionada por btrfs) de alguna manera niega la tranquilidad que aporta la RAM ECC. Sin embargo, no puedo pensar en una buena manera:

• btrfs no admite archivos de intercambio en absoluto. Puede configurar un dispositivo de bucle desde un archivo btrfs y hacer un intercambio sobre eso. Pero eso tiene problemas:
  • Las escrituras aleatorias no funcionan bien: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • La sugerencia allí para deshabilitar la copia en escritura también deshabilitará la suma de comprobación, lo que anulará el objetivo de este ejercicio. Suponen que el archivo de datos tiene sus propias protecciones internas.
• ZFS en Linux permite usar un ZVOL como intercambio, lo que supongo que podría funcionar: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap ; sin embargo, según mi lectura, ZFS normalmente requiere memoria y hacer que funcione en un intercambio -solo la aplicación suena como algo de trabajo para resolverlo. Creo que esta no es mi primera opción. ¿Por qué tendrías que usar un módulo de kernel fuera del árbol solo para tener un intercambio confiable que me supera? Seguramente hay una manera de lograr esto con la mayoría de las distribuciones / kernels de Linux modernas en la actualidad.
• En realidad, había un subproceso en una lista de correo del kernel de Linux con parches para habilitar las sumas de verificación dentro del administrador de memoria, exactamente por las razones que discuto en esta pregunta: http://thread.gmane.org/gmane.linux.kernel/989246 - desafortunadamente, por lo que puedo decir, el parche murió y nunca llegó río arriba por razones desconocidas para mí. Lástima, sonaba como una buena característica. Por otro lado, si coloca un intercambio en un RAID-1, si la corrupción está más allá de la capacidad de reparación de la suma de comprobación, querrá que el administrador de memoria intente leer desde la otra unidad antes de entrar en pánico o lo que sea probablemente fuera del alcance de lo que debe hacer un administrador de memoria.

En resumen:

• RAM tiene ECC para corregir errores
• Los archivos en almacenamiento permanente tienen btrfs para corregir errores
• Intercambio tiene ??? <--- esta es mi pregunta

Confiamos en la integridad de los datos recuperados del intercambio porque el hardware de almacenamiento tiene sumas de verificación, CRC y demás.

En uno de los comentarios anteriores, usted dice:

cierto, pero no protegerá contra cambios de bits fuera del disco

"Es" significa las sumas de comprobación del disco aquí.

Eso es cierto, pero SATA usa CRC de 32 bits para comandos y datos. Por lo tanto, tiene una probabilidad de 1 en 4 mil millones de corromper los datos de forma indetectable entre el disco y el controlador SATA. Eso significa que una fuente de error continuo podría introducir un error con la frecuencia que se transfiere cada 125 MiB, pero una fuente de error rara y aleatoria como los rayos cósmicos causaría errores indetectables a una velocidad extremadamente pequeña.

Tenga en cuenta también que si tiene una fuente que causa un error no detectado a una velocidad cercana a uno por cada 125 MiB transferidos, el rendimiento será terrible debido a la gran cantidad de errores detectados que requieren una nueva transferencia. El monitoreo y el registro probablemente lo alertarán sobre el problema a tiempo para evitar daños no detectados.

En cuanto a las sumas de verificación del medio de almacenamiento, cada disco SATA (y antes, PATA) usa sumas de verificación por sector de algún tipo. Una de las características de los discos duros "empresariales" son los sectores más grandes protegidos por características adicionales de integridad de datos , lo que reduce en gran medida la posibilidad de un error no detectado.

Sin tales medidas, no tendría sentido el grupo de sectores de repuesto en cada disco duro: el disco en sí no podría detectar un sector defectuoso, por lo que nunca podría intercambiar sectores nuevos.

En otro comentario, preguntas:

si SATA es tan confiable, ¿por qué hay sistemas de archivos con suma de verificación como ZFS, btrfs, ReFS?

En términos generales, no estamos pidiendo intercambio para almacenar datos a largo plazo. El límite en el almacenamiento de intercambio es el tiempo de actividad del sistema , y la mayoría de los datos en el intercambio no duran tanto, ya que la mayoría de los datos que pasan por el sistema de memoria virtual de su sistema pertenecen a procesos de vida mucho más corta.

Además de eso, los tiempos de actividad generalmente se han acortado a lo largo de los años, con la mayor frecuencia de kernel y libcactualizaciones, virtualización, arquitecturas en la nube, etc.

Además, la mayoría de los datos en el intercambio se usan inherentemente en un sistema bien administrado, que es uno que no se queda sin RAM principal. En dicho sistema, las únicas cosas que terminan en intercambio son páginas que el programa no usa con frecuencia, si es que alguna vez lo hace. Esto es más común de lo que imaginas. La mayoría de las bibliotecas dinámicas que enlazan sus programas tienen rutinas que su programa no usa, pero el enlazador dinámico tuvo que cargarlas en la RAM . Cuando el sistema operativo ve que no está utilizando todo el texto del programa en la biblioteca, lo intercambia, dejando espacio para el código y los datos que están utilizando sus programas . Si tales páginas de memoria intercambiadas están dañadas, ¿quién lo sabría?

Compare esto con ZFS, donde esperamos que los datos se almacenen de manera duradera y persistente, de modo que duren no solo más allá del tiempo de actividad actual del sistema, sino también más allá de la vida útil de los dispositivos de almacenamiento individuales que componen el sistema de almacenamiento. ZFS y tal están resolviendo un problema con una escala de tiempo de aproximadamente dos órdenes de magnitud más larga que el problema resuelto por el intercambio. Por lo tanto, tenemos requisitos de detección de corrupción mucho más altos para ZFS que para el intercambio de Linux.

ZFS y demás difieren del intercambio en otra forma clave aquí: no RAID intercambiamos sistemas de archivos juntos. Cuando se usan múltiples dispositivos de intercambio en una sola máquina, es un esquema JBOD , no como RAID-0 o superior. (por ejemplo, el esquema de archivos de intercambio encadenados de macOS , Linux swapon, etc.) Dado que los dispositivos de intercambio son independientes, en lugar de ser interdependientes como con RAID, no necesitamos una suma de verificación extensa porque reemplazar un dispositivo de intercambio no implica buscar otros dispositivos de intercambio interdependientes para los datos que deben ir en el dispositivo de reemplazo. En términos de ZFS, no adaptamos dispositivos de intercambio de copias redundantes en otros dispositivos de almacenamiento.

Todo esto significa que debe usar un dispositivo de intercambio confiable. Una vez utilicé un gabinete USB HDD externo de $ 20 para rescatar un grupo ZFS enfermo, solo para descubrir que el gabinete en sí mismo no era confiable, introduciendo errores propios en el proceso. La fuerte suma de verificación de ZFS me salvó aquí. No puede salirse con la suya con un trato tan arrogante de los medios de almacenamiento con un archivo de intercambio. Si el dispositivo de intercambio está muriendo y, por lo tanto, se acerca al peor de los casos en el que podría inyectar un error indetectable cada 125 MiB transferidos, simplemente tiene que reemplazarlo lo antes posible.

El sentido general de paranoia en esta pregunta recae en una instancia del problema de los generales bizantinos . Lea sobre eso, reflexione sobre la fecha de 1982 en el documento académico que describe el problema al mundo de la informática y luego decida si usted, en 2019, tiene nuevas ideas para agregar a este problema. Y si no, entonces tal vez solo usará la tecnología diseñada por tres décadas de graduados de CS que todos conocen el problema de los generales bizantinos.

Este es un terreno bien pisado. Probablemente no se te ocurra una idea, objeción o solución que no haya sido discutida hasta la muerte en las revistas de informática.

Ciertamente, SATA no es completamente confiable, pero a menos que usted se una a la academia o a uno de los equipos de desarrollo del kernel, no podrá agregar materialmente al estado del arte aquí. Estos problemas ya están bien manejados, como ya ha notado: ZFS, btrfs, ReFS ... Como usuario del sistema operativo, simplemente tiene que confiar en que los creadores del sistema operativo se ocuparán de estos problemas por usted, porque también saben sobre los generales bizantinos.

Es actualmente no es práctico para poner el archivo de intercambio en la parte superior de ZFS o Btrfs, pero si lo anterior no se tranquiliza, se podría al menos ponerlo encima de XFS o ext4. Eso sería mejor que usar una partición de intercambio dedicada.

integridad dm

Ver: Documentation / device-mapper / dm-integrity.txt

dm-integritynormalmente se usaría en modo diario. En el caso de intercambio, puede hacer arreglos para hacerlo sin el diario. Esto podría reducir significativamente la sobrecarga de rendimiento. No estoy seguro de si tendría que volver a formatear la partición de intercambio de integridad en cada arranque, para evitar errores de captura después de un cierre impuro.

En el anuncio inicial dedm-integrity , el autor declara una preferencia por la "protección de la integridad de los datos en el nivel superior". En el caso del intercambio, eso abriría la posibilidad de almacenar las sumas de verificación en la RAM. Sin embargo, esa opción requeriría modificaciones no triviales al código de intercambio actual y aumentaría el uso de memoria. (El código actual rastrea el intercambio de manera eficiente usando extensiones, no páginas / sectores individuales).

DIF / DIX?

Oracle agregó el soporte DIX en Linux 2.6.27 (2008).

¿Usar DIX proporciona integridad de extremo a extremo?

Puede consultar a su vendedor. No sé cómo podrías saber si están mintiendo al respecto.

Se requiere DIX para proteger los datos en vuelo entre el SO (sistema operativo) y el HBA .

DIF por sí solo aumenta la protección de los datos en vuelo entre el HBA y el dispositivo de almacenamiento . (Ver también: presentación con algunas cifras sobre la diferencia en las tasas de error ).

Precisamente porque la suma de verificación en el campo de protección está estandarizada, es técnicamente posible implementar comandos DIX sin proporcionar ninguna protección para los datos en reposo. Solo haga que el HBA (o dispositivo de almacenamiento) regenere la suma de verificación en el momento de la lectura. Esta perspectiva quedó bastante clara por el proyecto DIX original.

• DIF / DIX son sumas de comprobación de bloques lógicos o ortogonales
  • ¡Todavía te amamos, btrfs!
  • Los errores de suma de comprobación de bloque lógico se utilizan para detectar datos corruptos
  • La detección ocurre en el tiempo de LECTURA
  • ... que podría ser meses después, se pierde el búfer original
  • Cualquier copia redundante también puede ser mala si el búfer original fue ilegible
• DIF / DIX trata sobre la prevención proactiva de la corrupción
  • En primer lugar, evitar que los datos incorrectos se almacenen en el disco
  • ... y descubrir problemas antes de que el búfer original se borre de la memoria

- lpc08-data-integrity.pdf de oss.oracle.com

Una de sus primeras publicaciones sobre DIX menciona la posibilidad de usar DIX entre el sistema operativo y HBA incluso cuando la unidad no es compatible con DIF.

La mendacidad completa es relativamente improbable en contextos "empresariales" en los que actualmente se utiliza DIX; la gente lo notaría. Además, DIF se basaba en hardware existente que podía formatearse con sectores de 520 bytes. El protocolo para usar DIF supuestamente requiere que primero vuelva a formatear la unidad, consulte, por ejemplo, el sg_formatcomando.

Lo más probable es una implementación que no siga el verdadero principio de principio a fin . Para dar un ejemplo, se menciona un proveedor que admite una opción de suma de comprobación más débil para DIX para guardar los ciclos de la CPU, que luego se reemplaza por una suma de verificación más fuerte más abajo en la pila. Esto es útil, pero no es una protección completa de extremo a extremo.

Alternativamente, un sistema operativo podría generar sus propias sumas de verificación y almacenarlas en el espacio de etiquetas de la aplicación. Sin embargo, no hay soporte para esto en Linux actual (v4.20) . El comentario, escrito en 2014, sugiere que esto podría deberse a que "muy pocos dispositivos de almacenamiento realmente permiten usar el espacio de etiqueta de la aplicación". (No estoy seguro de si esto se refiere al dispositivo de almacenamiento en sí, el HBA o ambos).

¿Qué tipo de dispositivos DIX están disponibles que funcionan con Linux?

La separación de los buffers de metadatos de datos e integridad, así como la elección en las sumas de verificación, se denominan Extensiones de integridad de datos [DIX]. Como estas extensiones están fuera del alcance de los organismos de protocolo (T10, T13), Oracle y sus socios están tratando de estandarizarlas dentro de la Asociación de la Industria de Redes de Almacenamiento.

- v4.20 / Documentation / block / data-integrity.txt

Wikipedia me dice que DIF está estandarizado en NVMe 1.2.1. Para los HBA SCSI, parece un poco difícil precisar esto si no tenemos un estándar al que señalar. Por el momento, podría ser más preciso hablar sobre la compatibilidad con "Linux DIX" :-). Hay dispositivos disponibles:

SCSI T10 DIF / DIX [sic] es totalmente compatible con Red Hat Enterprise Linux 7.4, siempre que el proveedor de hardware lo haya calificado y brinde soporte completo para la configuración particular de HBA y matriz de almacenamiento. DIF / DIX no es compatible con otras configuraciones, no es compatible para su uso en el dispositivo de arranque y no es compatible con invitados virtualizados.

En la actualidad, se sabe que los siguientes proveedores brindan este soporte ...

- Notas de la versión RHEL 7.5, Capítulo 16. Almacenamiento

Todo el hardware mencionado en las notas de la versión RHEL 7.5 es Fibre Channel.

No conozco este mercado Parece que DIX podría estar más ampliamente disponible en servidores en el futuro. No sé ninguna razón por la que estaría disponible para discos SATA de consumo, por lo que sé, ni siquiera hay un estándar de facto para el formato de comando. Me interesará ver si está más disponible en NVMe.

Intercambio tiene ??? <--- esta es mi pregunta

Swap todavía no está protegido en Linux (pero vea UPD).

Bueno, por supuesto, hay ZFS en Linux que es capaz de ser un almacenamiento de intercambio, pero todavía hay un bloqueo en algunas circunstancias, lo que revoca efectivamente esa opción.

Btrfs todavía no puede manejar archivos de intercambio . Mencionan el posible uso del loopback, aunque se observa que tiene un bajo rendimiento. Hay una indicación poco clara de que Linux 5 podría tenerlo finalmente (?) ...

Los parches para proteger el intercambio convencional en sí con sumas de comprobación no llegaron a la corriente principal.

Entonces, en general: no. Linux todavía tiene una brecha allí.

UPD : Como señala @ sourcejedi , existe una herramienta como dm-integridad. El kernel de Linux desde la versión 4.12 ha obtenido el objetivo del mapeador de dispositivos que se puede usar para proporcionar sumas de verificación a cualquier dispositivo de bloque general y aquellos que son para intercambio no son una excepción. Las herramientas no están ampliamente incorporadas en las principales distribuciones y la mayoría de ellas no tienen ningún soporte en el subsistema udev, pero eventualmente esto debería cambiar. Cuando se combina con un proveedor de redundancia, digamos que se coloca en una parte superior de MD aka Linux Software RAID, debería ser posible no solo detectar la descomposición de bits sino también redirigir la solicitud de E / S a datos saludables porque la integridad de dm indicaría que hay un problema y MD debe manejarlo.

No creo que haya una forma "canónica", así que lo siguiente es mi opinión personal.

Habiendo monitoreado el avance de btrfs desde el punto de vista de un usuario potencial, tengo que decir que todavía es algo oscuro para mí. Hay características que están maduras y listas para su uso en producción, y hay características que aparentemente son inmaduras y peligrosas de usar.

Personalmente, no tengo tiempo para decidir qué función usar y cuál no, dejé de lado el tiempo que necesitaría para descubrir cómo apagar o encender estas funciones.

En contraste, ZFS es sólido como una roca y maduro (en mi humilde opinión). Entonces, para responder a su pregunta, usaría ZFS (por cierto, no consume mucha memoria, ver a continuación).

Pero para usted, btrfs podría ser la opción correcta ya que ya lo está utilizando (si es que lo entendí bien), y uno de los comentarios anteriores muestra cómo usarlo para el intercambio.

Por pura casualidad, he puesto algunos servidores Linux en ZFS durante los últimos días, cada vez incluyendo el sistema de archivos raíz y el intercambio. Antes de hacer esto, hice una investigación exhaustiva, que me llevó varios días. Un breve resumen de lo que he aprendido:

Consumo de memoria de ZFS

Hay un malentendido común con respecto al consumo de memoria de ZFS. ZFS generalmente no consume mucha memoria; de hecho, se ejecuta con TB de almacenamiento en máquinas con 2 GB de RAM. Solo si usa la deduplicación (desactivada de manera predeterminada), entonces necesita mucha RAM.

Detección / corrección de errores de hardware

Si los mecanismos de detección / corrección de errores de SATA, PATA, RAID u otros son suficientes para la integridad de los datos es un tema que causa discusiones interminables e incluso guerras de llamas en todos los lugares de la red. En teoría, un dispositivo de almacenamiento de hardware debería informar (y posiblemente corregir) cualquier error que encuentre, y el hardware de transmisión de datos en todos los niveles (chipset, memoria, etc.) también debería hacerlo.

Bueno, no lo hacen en todos los casos, o reaccionan de manera superficial a los errores. Como ejemplo, tomemos una configuración típica de RAID5. Normalmente, si un disco tiene un problema, lo informará al RAID, que a su vez construye los datos que se leerán de los otros discos y los pasa, pero también los vuelve a escribir en el disco defectuoso (que a su vez probablemente vuelve a asignar el sector antes de escribir los datos); Si el mismo disco informa demasiados errores, el RAID lo desconecta e informa al administrador (si está configurado correctamente).

Hasta ahora, todo bien, pero hay casos en que los datos defectuosos salen de un disco sin que el disco informe un error (consulte la siguiente sección). La mayoría de los RAID pueden detectar esta situación utilizando la información de paridad, pero su reacción es estúpida: en lugar de informar el error y detener la transmisión de los datos, simplemente volverán a calcular la paridad en función de los datos defectuosos y escribirán la nueva paridad en la respectiva paridad. disco, marcando así los datos defectuosos como correctos para siempre.

¿Es ese un comportamiento razonable? Hasta donde sé, la mayoría de los controladores RAID5 de hardware e incluso md RAID de Linux funcionan de esta manera.

No sé acerca de la corrección de errores de btrfs, pero eventualmente debería leer los documentos cuidadosamente una vez más, especialmente si está utilizando el RAID de btrfs.

Pudrición silenciosa

A pesar de todas las guerras de llamas y las discusiones (pseudo) científicas: la realidad en su mayoría es diferente de la teoría, y la podredumbre silenciosa definitivamente ocurre, aunque la teoría podría decir lo contrario (la podredumbre silenciosa por lo general significa que los datos en el almacenamiento de hardware se corrompen sin que el dispositivo de almacenamiento informe un error cuando se leen estos datos, pero agregaré bits de volteo en cualquier parte de la ruta de transmisión a esta definición).

Que esto suceda no es mi opinión personal: al menos Google, Amazon y el CERN han publicado documentos detallados que cubren exactamente ese tema. Los documentos están disponibles públicamente para su descarga de forma gratuita. Han realizado experimentos sistemáticos con varios millones de discos duros y cientos de miles de servidores / dispositivos de almacenamiento, ya sea porque tenían problemas con la corrupción de datos no detectados o porque querían saber qué hacer para evitarlo antes de que ocurriera.

En resumen, los datos en sus granjas de servidores se han dañado con una tasa significativamente más alta que las estadísticas de MTBF u otra teoría podría esperar. Por significativamente mayor, me refiero a órdenes de magnitud.

Por lo tanto, la putrefacción silenciosa de los bits, es decir, la corrupción de datos no detectada en cualquier punto de la ruta de transmisión, es un problema de la vida real.

Datos de por vida

Warren Young tiene razón cuando dice que los datos de intercambio tienen una vida útil corta. Pero me gustaría agregar la siguiente consideración: no solo los datos (en el sentido de los documentos) se intercambian, sino (quizás incluso más probablemente) partes del O / S u otro software en ejecución . Si tengo un intercambio de MP3, podría vivir un poco. Si (debido a una situación extrema) partes del software de mi servidor httpd de producción están en intercambio, de ninguna manera puedo vivir con un cambio que luego me lleva a ejecutar código corrupto si no se detecta.

Epílogo

Para mí, ZFS resuelve estos problemas o, más precisamente, los aleja de los discos a la memoria y, por lo tanto, reduce la probabilidad de pudrición de bits silenciosa en algunos órdenes de magnitud. Además, si se configura correctamente (es decir, espejos en lugar de RAID), proporciona una corrección de errores limpia y razonable que funciona como se esperaba y, después de todo, se puede entender fácilmente.

Dicho esto, tenga en cuenta que nunca obtendrá una seguridad absoluta. Personalmente, confío en mi RAM ECC más que en mis discos, y estoy convencido de que ZFS con sus sumas de verificación de extremo a extremo reduce la probabilidad de problemas en órdenes de magnitud. Sin embargo, nunca recomendaría usar ZFS sin ECC RAM.

Descargo de responsabilidad: de ninguna manera estoy asociado con ningún proveedor o desarrollador de ZFS. Esto es cierto para todas las variantes (horquillas) de ZFS. Me acabo de hacer fan en los últimos días ...