☰

Странные повреждения файлов в ext4

tag-icon • tag-icon hard-drive ssd ext4 corruption
Странные повреждения файлов в ext4

Недавно я столкнулся с тем, что, по-видимому, является сценарием повреждения диска, и мне хотелось бы лучше в нем разобраться.

У меня есть сервер сборки, с которым я работаю ежедневно. Во время одной полной сборки недавнего релиза LLVM, которая остановилась со странным сообщением об ошибке, я получил этот фрагмент для одного сгенерированного файла ( X86GenDisassemblerTables.inc):

...
/* 0xa5 */
{ /* ModRMDecision */
 MODRM_ONEENTRY,
 0 /* EmptyTable */
},
/* 0xa6 */
{ /* ModRMDecision */
 MODÒM_ONEENTRY,                # Ò = 0xD2
 0 /* EmptyTable */             # R = 0x52
},
/* 0xa7 */
{ /* ModRMDecision */
 MODRM_ONEENTRY,
 0 /* EmptyTable */
},
...

Похоже, это однобитовое повреждение файла. Я удалил файл, сборка сгенерировала его снова и успешно завершилась.

И сегодня, вдругоймашина, этот .dфайл был создан во время сборки:

output-gcc-8.2.0-x86_64-linux-gnu/obj/headers.hpp.gch: src/headers.hpp
pp      # What's this?

Все остальное — размер файла, разрешения, даже завершающий символ новой строки — было на месте. Удаление файла также позволило сборке сгенерировать его снова без проблем.

Являются ли эти случаи законными повреждениями диска? Какие инструменты я могу использовать для диагностики? Эти диски представляют собой SSD-накопители возрастом один и два года, работающие под управлением файловой системы ext4.

решение1

Вы можете начать с теста RAM. Хард-дайвы обычно знают, когда у них происходит сбой чтения или записи. Если вы еще не получаете ошибки жесткого диска в сообщениях ядра и вы не используете ECC RAM, я бы заподозрил RAM, а не жесткий диск.

Связанный контент