LINUX.ORG.RU
Форум — Admin  

Не пойму что не так с HDD...

 ,


1

1

Друзья, на одном из серверов стало сыпаться такое:

Device: /dev/sdc [SAT], 3 Currently unreadable (pending) sectors.

Сделал так:

smartctl -a /dev/sdc|grep "Current_Pending_Sector\|Reallocated_Sector_Ct\|Offline_Un"
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

Вижу трёшку по предположительно проблемным секторам.

Сделал так:

echo check > /sys/block/md6/md/sync_action

После проверки массива, стало так: 

smartctl -a /dev/sdc|grep "Current_Pending_Sector\|Reallocated_Sector_Ct\|Offline_Un"
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

TLER на диске отключен.

Как такое может быть что после scrub исчезли все подозрения на диск? И при этом нету remap секторов...

smartctl - на длинном тесте, так же выявлял сбойные сектора.

★★★★★

Последнее исправление: DALDON (всего исправлений: 2)

http://www.ixbt.com/storage/hdd-smart-testing.shtml

При попытке записи в сектор диск сначала проверяет, не находится ли этот сектор в списке кандидатов. Если сектор там не найден, запись проходит обычным порядком. Если же найден, проводится тестирование этого сектора записью-чтением. Если все тестовые операции проходят нормально, то диск считает, что сектор исправен. (Т. е. был т. н. «софт-бэд» — ошибочный сектор возник не по вине диска, а по иным причинам: например, в момент записи информации отключилось электричество, и диск прервал запись, запарковав БМГ. В итоге данные в секторе окажутся недописанными, а контрольная сумма сектора, зависящая от данных в нём, вообще останется старой. Налицо будет расхождение между нею и данными в секторе.) В таком случае диск проводит изначально запрошенную запись и удаляет сектор из списка кандидатов. При этом атрибут 197 уменьшается, также возможно увеличение атрибута 196.

То есть если всё починилось и ремапа не было - атрибут не обязан увеличиваться...

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Красотища то какая...

Ох ты мать твою!

То есть, в моём случае очень даже возможно что при проведении scrub, mdadm найдя проблемы в чтении догадался туда начать перезаписывать, и при перезаписи всё стало хорошо?

P.S., я не могу посмотреть пытался ли mdadm это делать или нет, насколько я понимаю, так-как у меня raid1, а там:

RAID1 and RAID10 Notes on Scrubbing

Due to the fact that RAID1 and RAID10 writes in the kernel are unbuffered, an array can have non-0 mismatch counts even when the array is healthy. These non-0 counts will only exist in transient data areas where they don't pose a problem. However, since we can't tell the difference between a non-0 count that is just in transient data or a non-0 count that signifies a real problem. This fact is a source of false positives for RAID1 and RAID10 arrays. It is however recommended to still scrub to catch and correct any bad sectors there might be in the devices.

Вот тут у меня большое очень число:

cat /sys/block/md6/md/mismatch_cnt

104448

Спасибо, за очень толковый ответ!

DALDON ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin