Recientemente entré en contacto con lo que parecen ser escenarios de corrupción de disco y me gustaría comprenderlos mejor.
Tengo un servidor de compilación con el que trabajo a diario. Durante una compilación completa de una versión reciente de LLVM que se detuvo con un extraño mensaje de error, obtuve este extracto de un archivo generado ( X86GenDisassemblerTables.inc):
...
/* 0xa5 */
{ /* ModRMDecision */
MODRM_ONEENTRY,
0 /* EmptyTable */
},
/* 0xa6 */
{ /* ModRMDecision */
MODÒM_ONEENTRY, # Ò = 0xD2
0 /* EmptyTable */ # R = 0x52
},
/* 0xa7 */
{ /* ModRMDecision */
MODRM_ONEENTRY,
0 /* EmptyTable */
},
...
Esto parece ser una corrupción de archivo de un solo bit. Eliminé el archivo, la compilación lo generó nuevamente y se completó con éxito.
Y hoy, en undiferentemáquina, este .darchivo se produjo durante una compilación:
output-gcc-8.2.0-x86_64-linux-gnu/obj/headers.hpp.gch: src/headers.hpp
pp # What's this?
Todo lo demás (tamaño del archivo, permisos, incluso la nueva línea final) estaba en su lugar. Eliminar el archivo también permitió que la compilación lo generara nuevamente sin problemas.
¿Son estos casos legítimos de corrupción de disco? ¿Qué herramientas puedo utilizar para diagnosticar esto? Estos discos son, respectivamente, SSD de uno y dos años de antigüedad que ejecutan sistemas de archivos ext4.
Respuesta1
Es posible que desees comenzar con una prueba de RAM. Las inmersiones difíciles normalmente saben cuándo tienen un error de lectura o escritura. Si aún no recibe errores del disco duro en los mensajes del kernel y no está usando RAM ECC, sospecho que la RAM está sobre el disco duro.