☰

La memoria caché pierde sincronización con el disco

tag-icon • tag-icon linux memory cache
La memoria caché pierde sincronización con el disco

(Servidor Ubuntu Linux, 64 bits) Estaba solucionando un problema con un archivo (~3,0 GB) que acababa de descargar, pero no pasaba la prueba de integridad, cuando descubrí algo realmente inusual.

Primero, este es el MD5 del archivo después de la descarga, que no coincide con el valor esperado:

~% md5sum media.iso 
5d74facb904cc1765a468354908a8f34  media.iso

Pasa un tiempo, nada debería haber cambiado el archivo durante este tiempo, pero cuando fui a revisar el archivo nuevamente:

~% md5sum media.iso
a5b97c5016afb39bd67ccfc3fa6ca59e  media.iso

Esto fue realmente inesperado. Como tengo mucha RAM, sospeché que esto era efecto del almacenamiento en caché y que algo andaba mal. Decidí volver a intentarlo con todo el archivo del disco, para mi sorpresa:

~% sudo sysctl -w vm.drop_caches=3    # This linux command invalidates
vm.drop_caches = 3                    # everything in the memory cache.
~% md5sum media.iso
2992aa6270f6e1de9154730ed3beedc1  media.iso

Lo rehice y ahora parece mantenerse consistente, aunque todavía no es el valor que esperaba. Ciertamente,el contenido de la memoria caché era diferente del contenido del disco. Este es el gran problema.

Para arreglar la descarga, creé un torrent en la máquina de origen y lo abrí en la máquina de destino. Cinco fragmentos de 1 MB de ~3,0 GB fallaron en la verificación de integridad. Utilicé el torrent para arreglar estos fragmentos de archivos y comprobar que la integridad del archivo está bien.

El problema ahora es determinar dónde se desincronizaron los datos.

  1. Probé la memoria conmemtest86+, todo menos la prueba de desvanecimiento de bits. Esperaba ver algún módulo de memoria fallando, pero no había nada. Todo está bien.
  2. El sistema de archivos es Ext4, sobre LVM2, sobre una matriz RAID5 de 3 discos. Ext4 se considera estable y, si los datos fueran inconsistentes entre los discos, mdadm lo habría advertido. Pero no hay nada en los registros. Los registros de errores SMART están limpios, los discos son nuevos (tienen menos de 30 días de "horas de encendido").
  3. Estoy buscando información sobre errores de pérdida de datos en mi kernel actual (2.6.35), pero, por lo que miré, no parece haber nada.

¿Alguna idea sobre qué más podría verificar o dónde podría estar exactamente el defecto/error?

Es un Ubuntu 10.10 de 64 bits, Core i7 930, 6 GB de RAM no ECC.

Actualizar:Confirmé que los archivos se escriben correctamente en el disco y que las páginas se modifican después de leerlas desde el disco, mientras están en la memoria. Hice muchas más pruebas de memoria (lo dejé haciendo una prueba de desvanecimiento durante la noche) y todavía nada. Todos los módulos de memoria parecen estar bien.

Algunas pruebas más:

~% md5sum media.iso 
cc8bcf1ce67ff7704eadc2222650c087  media.iso
~% cp media.iso tmp1
~% md5sum tmp1 
bde6c54b2d7b03404b43056b908036ed  tmp1
~% md5sum media.iso 
134f607cf4c633ef11d2576d1c635d08  media.iso    # ← THIS IS THE CORRECT VALUE
~% cmp -l media.iso tmp1
  98697009 101 121
~% udiff <(xxd -s ... media.iso) <(xxd -s ... tmp1 )
--- /proc/self/fd/11    2010-11-03 14:52:55.649433000 -0200
+++ /proc/self/fd/13    2010-11-03 14:52:55.649433000 -0200
@@ -13,7 +13,7 @@
 5e1fef1: 280f 5a87 37d2 e6d6 647d bebe f04e 64d8  (.Z.7...d}...Nd.
 5e1ff01: 19a5 2ff4 178b 1e37 afb0 e914 e03f bd62  ../....7.....?.b
 5e1ff11: 2b8d 4245 985f a9f8 a993 1f51 6d31 30e7  +.BE._.....Qm10.
-5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3541  .t.5........ .5A
+5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3551  .t.5........ .5Q
 5e1ff31: 387b f226 6348 fabc 1eae 67ef adda c3b6  8{.&cH....g.....
 5e1ff41: a931 bf29 690f 25f9 8922 6dcc 009f 60a5  .1.)i.%.."m...`.
 5e1ff51: 559a 9d03 92cb fb5c a75f a26e 0954 0af4  U......\._.n.T..

~% md5sum media.iso        
54d67cc4dcad49b6d1bf6619074b471c  media.iso
~% direcat media.iso|md5sum
134f607cf4c633ef11d2576d1c635d08  -
~% direcat media.iso | cmp -l media.iso -
  98697009 121 101
 231297649 146 147
 519630641 177 157
2291859249 377 357
2442055473 127 107
2907131697 171 151

( direcates una versión que catse lee con O_DIRECT, es decir, sin pasar por el caché de la página)

Hay un patrón claro: siempre sucede con el segundo byte en una alineación de 16 bytes. En ese byte, casi siempre el bit 4 (LSB) cambia a uno, pero hubo un caso en el que el bit 2 cambia a cero.

Respuesta1

Si la suma md5 de un archivo cambia, existen varias explicaciones posibles, en orden de probabilidad:

  • El archivo fue escrito en.
  • Su RAM está defectuosa (u otro componente de la placa base, pero la RAM es, con diferencia, la más propensa a fallar).
  • Su almacenamiento está defectuoso. (Es poco probable porque el almacenamiento defectuoso generalmente genera archivos ilegibles, no datos dañados).
  • Un error del kernel, quizás en el código del sistema de archivos. (Muy poco probable con ext4.)

Tenga en cuenta que la "inconsistencia entre el disco y la caché" es un síntoma, no una causa. Ni siquiera es un síntoma que hayas observado: lo que observaste fue una diferencia entre la memoria en el momento T y la memoria en el momento T'.

Si está seguro de que el archivo no se estaba modificando, entonces la explicación más probable es una RAM defectuosa. Desafortunadamente, las pruebas de memoria no siempre detectan una RAM defectuosa. Si puede obtener dos copias diferentes del archivo, compárelas ( cmp -l file1 file2); si las diferencias están alineadas (por ejemplo, las diferencias siempre están en el bit 42 de una secuencia de 16 bytes) o consisten en bloques desplazados (el signo de corrupción que se produce en una variable de puntero), todos los signos apuntan a una RAM defectuosa.

información relacionada