Recently I came in contact with what appears to be disk corruption scenarios, and I would like to understand them better.
I have a build server which I work with daily. During one full build of a recent LLVM release which stopped with a strange error message, I got this excerpt for one generated file (X86GenDisassemblerTables.inc
):
...
/* 0xa5 */
{ /* ModRMDecision */
MODRM_ONEENTRY,
0 /* EmptyTable */
},
/* 0xa6 */
{ /* ModRMDecision */
MODÒM_ONEENTRY, # Ò = 0xD2
0 /* EmptyTable */ # R = 0x52
},
/* 0xa7 */
{ /* ModRMDecision */
MODRM_ONEENTRY,
0 /* EmptyTable */
},
...
This seems to be a single-bit file corruption. I removed the file, the build generated it again and completed successfully.
And today, in a different machine, this .d
file was produced during a build:
output-gcc-8.2.0-x86_64-linux-gnu/obj/headers.hpp.gch: src/headers.hpp
pp # What's this?
Everything else -- file size, permissions, even the terminating newline -- was in place. Removing the file also allowed the build to generate it again without problems.
Are these legitimate cases of disk corruption? Which tools can I use to diagnose this? These disks are, respectively, one and two-year old SSDs running ext4 file systems.
Comments
Post a Comment