Прежде чем добавить диск для замены в массив, я выполнил этот сценарий, чтобы убедиться, что мне не нужно отправлять замену обратно производителю:
date
badblocks -b 4096 -c 4096 /dev/sdd
date
hdparm -Tt /dev/sdd
date
Его выполнение дало такой результат примерно через 8 часов, давая мне знать, что я могу оставить диск:
Thu Jan 28 20:07:54 CST 2021
Fri Jan 29 04:37:40 CST 2021
/dev/sdd:
Timing cached reads: 34840 MB in 1.99 seconds = 17546.64 MB/sec
Timing buffered disk reads: 728 MB in 3.01 seconds = 242.16 MB/sec
Fri Jan 29 04:37:40 CST 2021
В то время как плохие блоки работал, примерно раз в час я выполнял Strace чтобы посмотреть, как дела. Каждый раз, когда я его выполнял, я замечал, что частота системных вызовов снижается. И каждый раз, когда я выполнял его, я видел этот шаблон, который заверил меня, что он прогрессирует (т.е. значения поиска увеличиваются на 16M, размер вызовов чтения):
lseek(3, 5929403678720, SEEK_SET) = 5929403678720
read(3, " "..., 16777216) = 16777216
lseek(3, 5929420455936, SEEK_SET) = 5929420455936
read(3, " "..., 16777216) = 16777216
я посмотрел на top. Наверху было badblocks, занимая около 3% ядра, и никакой другой процесс на этой частной машине ничего не делал. Прочитав это, я решил прочитать исходный код (в частности test_ro функция). Не вижу проблем, спрашиваю:
- Что могло быть источником пандуса? А пандус где каждая итерация цикла выполняется медленнее, чем предыдущая.
- Могу ли я обойти это, только перезапустив
badblocksпо последнему известному смещению? - Будут ли плохие блоки отображаться только в конце выполнения или при их обнаружении? В страница руководства не дает этого понять.
Я использую e2fsprogs Version: 1.42.13-1ubuntu1.2, который представляет собой пакет, содержащий badblocks.