Наш сервер имеет два независимых жестких диска без RAID.
Один жесткий диск только для хранения ненужных / временных данных, где мы обычно удаляем временные данные с помощью алгоритма LRU.
У нас на жестком диске есть файл размером 10 КБ, некоторые файлы не читаются (мы не знаем почему).
Мы уже сделали fsck на этом диске при первом запуске говорится, что исправлены некоторые ошибки, но проблема не устранена.
Всякий раз, когда мы пытаемся прочитать этот нечитаемый файл, наша средняя загрузка становится высокой:
cp: overwrite `/tmp/t.mp4'? y
cp: reading `mq/full/68156.3gp': Input/output error
Судя по описанным до сих пор симптомам, наиболее вероятным объяснением является наличие на жестком диске нескольких поврежденных секторов.
Вы можете попробовать использовать ddrescue скопировать все хорошие сектора на новый диск. Это должно восстановить все файлы, которые можно восстановить, а остальные будут давать неверные данные при чтении.
Причина, по которой вы видите высокую среднюю нагрузку, заключается в том, что как только вы пытаетесь прочитать плохой сектор, жесткий диск будет очень стараться прочитать этот сектор. Между тем все остальное, пытающееся получить доступ к диску, придется подождать. При средней загрузке учитывается все, что находится в очереди.
Как только вы получите ошибку EIO, нагрузка быстро упадет. Но поскольку среднее значение нагрузки является экспоненциально затухающим средним за период, число будет оставаться высоким в течение некоторого времени после того, как нагрузка исчезнет.
Причина fsck не сообщает о каких-либо проблемах, так как проверяет логическую целостность метаданных. Для этого не нужно читать фактическое содержимое каких-либо файлов. Чтение всего содержимого файлов будет слишком медленным для нормального использования fsck.
После того как вы попытались прочитать файл и получили ошибку, вы сможете проверить, что произошло, просмотрев журнал ядра (либо запустив dmesg или просматривая лог-файлы).
Попытка прочитать каждый файл на диске - это один из способов найти все затронутые файлы, но это не самый быстрый. Тщательная интерпретация вывода ddrescue, вероятно, самый быстрый способ определить, какие файлы затронуты.