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