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, dices:
cierto, pero no protegerá contra cambios de bits fuera del propio disco
"It" significa las sumas de verificació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 dañar los datos de manera indetectable entre el disco y el controlador SATA. Eso significa que una fuente de error continua podría introducir un error cada 125 MiB transferidos, pero una fuente de error aleatoria rara como los rayos cósmicos causaría errores indetectables a una tasa muy pequeña.
Tenga en cuenta también que si tiene una fuente que provoca un error no detectado a una tasa cercana a uno por cada 125 MiB transferidos, el rendimiento será terrible debido al elevado número de detectados errores que requieren una nueva transferencia. La supervisión y el registro probablemente le alertarán sobre el problema a tiempo para evitar la corrupción no detectada.
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 funciones 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 de 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 del 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 el aumento de la frecuencia del kernel y libc actualizaciones, virtualización, arquitecturas en la nube, etc.
Además, la mayoría de los datos en el intercambio están intrínsecamente en desuso en un sistema bien administrado, ya que no se queda sin RAM principal. En tal sistema, las únicas cosas que terminan en el intercambio son las 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 vinculan sus programas tienen rutinas en ellas que su programa no usa, pero el vinculador 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 cambia, dejando espacio para el código y los datos que sus programas son. usando. Si tales páginas de memoria intercambiadas están dañadas, ¿quién lo sabría?
Compare esto con los gustos de 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 similares están resolviendo un problema con una escala de tiempo de aproximadamente dos órdenes de magnitud mayor que el problema resuelto por 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 similares difieren del intercambio en otra forma clave aquí:no intercambiamos sistemas de archivos de intercambio RAID juntos. Cuando varios dispositivos de intercambio están en uso en una sola máquina, es un esquema JBOD, no como RAID-0 o superior. (por ejemplo, esquema de archivos de intercambio encadenados de macOS, swapon de Linux , etc.) Dado que los dispositivos de intercambio son independientes, en lugar de interdependientes como con RAID, no necesitamos una suma de verificación extensa porque reemplazar un dispositivo de intercambio no implica buscar en otros dispositivos de intercambio interdependientes los datos que deben ir en el dispositivo de reemplazo. . En términos de ZFS, no recuperamos dispositivos de intercambio de copias redundantes en otros dispositivos de almacenamiento.
Todo esto significa que debe usar un dispositivo de intercambio confiable. Una vez usé un gabinete de HDD USB externo de $ 20 para rescatar un grupo ZFS en problemas, solo para descubrir que el gabinete no era confiable en sí mismo, lo que introducía errores propios en el proceso. La fuerte suma de verificación de ZFS me salvó aquí. No puede salirse con la suya con un tratamiento tan arrogante de los medios de almacenamiento con un archivo de intercambio. Si el dispositivo de intercambio se está agotando 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 debe reemplazarlo lo antes posible.
El sentido general de paranoia en esta pregunta se reduce a una instancia del problema de los generales bizantinos. Lea sobre eso, reflexione sobre la fecha de 1982 en el artículo académico que describe el problema para el mundo de la informática y luego decida si usted, en 2019, tiene nuevas ideas para agregar a este problema. Y si no, tal vez simplemente usará la tecnología diseñada por tres décadas de graduados en informática que conocen el problema de los generales bizantinos.
Este es un terreno bien pisado. Probablemente no se le ocurra una idea, objeción o solución que no haya sido discutida hasta el cansancio en las revistas de informática.
SATA ciertamente no es completamente confiable, pero a menos que vaya a unirse a la academia o a uno de los equipos de desarrollo del kernel, no estará en condiciones de agregar materialmente al estado del arte aquí. Estos problemas ya están bajo control, como ya habrás notado:ZFS, btrfs, ReFS... Como usuario del sistema operativo, simplemente debes confiar en que los creadores del sistema operativo se encargarán de estos problemas por ti, porque también saben sobre los generales bizantinos.
Actualmente no es práctico poner su archivo de intercambio encima de ZFS o Btrfs, pero si lo anterior no le tranquiliza, al menos podría ponerlo encima de xfs o ext4. Eso sería mejor que usar una partición de intercambio dedicada.
Permuta tiene??? <--- esta es mi pregunta
El intercambio aún 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 aún 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 de bucle invertido, aunque se observa que tiene un rendimiento deficiente. Hay una indicación poco clara de que Linux 5 podría tenerlo finalmente (?)…
Los parches para proteger el propio intercambio convencional con sumas de verificación no se generalizaron.
Entonces, en general:no. Linux todavía tiene una brecha allí.
UPD. :Como señala @sourcejedi, existe una herramienta como dm-integrity. El kernel de Linux desde la versión 4.12 ha obtenido el objetivo del mapeador de dispositivos que se puede utilizar 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 la parte superior de MD, también conocido como Linux Software RAID, debería ser posible no solo detectar bit rot, sino también redirigir la solicitud de E/S a datos saludables porque dm-integrity indicaría que hay un problema y MD debe manejarlo.
integridad dm
Ver:Documentación/device-mapper/dm-integrity.txt
dm-integrity normalmente se usaría en el modo de diario. En el caso del intercambio, puede prescindir del diario. Esto podría reducir significativamente la sobrecarga de rendimiento. No estoy seguro de si necesitará volver a formatear la partición de integridad de intercambio en cada arranque, para evitar la captura de errores después de un apagado no limpio.
En el anuncio inicial de dm-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 la memoria. (El código actual rastrea el intercambio de manera eficiente usando extensiones, no páginas/sectores individuales).
¿DIF/DIX?
Oracle agregó compatibilidad con DIX en Linux 2.6.27 (2008).
¿El uso de DIX proporciona integridad de extremo a extremo?
Podría consultar a su proveedor. No sé cómo puedes saber si están mintiendo al respecto.
Se requiere DIX para proteger los datos en tránsito entre el SO (sistema operativo) y el HBA .
DIF por sí solo aumenta la protección de los datos en tránsito 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 ninguno protección de datos en reposo. Simplemente haga que el HBA (o dispositivo de almacenamiento) regenere la suma de comprobación en el momento de la lectura. Esta perspectiva quedó bastante clara en el proyecto DIX original.
- DIF/DIX son ortogonales a sumas de comprobación de bloques lógicos
- ¡Todavía te amamos, btrfs!
- Los errores de suma de comprobación de bloques lógicos se utilizan para detectar datos dañados
- La detección ocurre en el momento de LEER
- ... lo 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 distorsionado
- DIF/DIX tratan de prevenir la corrupción de manera proactiva
- Evitar que los datos incorrectos se almacenen en el disco en primer lugar
- ... 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 OS y HBA incluso cuando la unidad no es compatible con DIF.
La mendacidad completa es relativamente poco probable en contextos "empresariales" donde actualmente se usa DIX; la gente lo notaría. Además, DIF se basó 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, p. el sg_format dominio.
Lo que es más probable es una implementación que no siga el verdadero principio de extremo a extremo. Para dar un ejemplo, se menciona un proveedor que admite una opción de suma de verificación más débil para que DIX ahorre ciclos de 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 permiten usar el espacio de etiquetas de la aplicación". (No estoy seguro de si esto se refiere al propio dispositivo de almacenamiento, al HBA o a ambos).
¿Qué tipo de dispositivos DIX están disponibles que funcionan con Linux?
La separación de los búferes de datos y metadatos de integridad, así como la elección de las sumas de verificación, se conoce como Extensiones de integridad de datos [DIX]. Como estas extensiones están fuera del alcance de los cuerpos de protocolo (T10, T13), Oracle y sus socios están tratando de estandarizarlas dentro de la Storage Networking Industry Association.
-- v4.20/Documentación/bloque/integridad-de-datos.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 apuntar. Por el momento, podría ser más preciso hablar sobre el soporte "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 de arreglo de almacenamiento y HBA en particular. 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.
Actualmente, se sabe que los siguientes proveedores brindan este soporte...
-- Notas de la versión de RHEL 7.5, Capítulo 16. Almacenamiento
Todo el hardware mencionado en las notas de la versión de RHEL 7.5 es Fibre Channel.
No conozco este mercado. Parece que DIX podría estar más disponible en los servidores en el futuro. No conozco ninguna razón por la que estaría disponible para discos SATA de consumo; hasta donde yo sé, ni siquiera existe un estándar de facto para el formato de comando. Me interesará ver si está disponible más ampliamente en NVMe.