Ошибки чтения жесткого диска, которые ... останавливаются?

Моя история начинается довольно просто. У меня есть легкий сервер, работающий под управлением Arch Linux, который хранит большую часть своих данных на RAID-1, состоящем из двух дисков SATA. Работало без проблем около 4 месяцев. Затем внезапно я начал получать ошибки чтения на одном из дисков. Всегда сообщения выглядели так:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Каждая ошибка жаловалась на другой номер сектора и сопровождалась задержкой доступа пользователя (меня) к диску на несколько секунд.

Я проверил вывод smartctl и увидел следующий вывод (несущественные части обрезаны):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Оглядываясь в журналах, я обнаружил, что ошибки на самом деле происходили в течение нескольких дней, в основном во время резервного копирования, но также часто при очень легком использовании (то есть примерно каждый пятый раз, когда я пытался сохранить текстовый файл). Я пришел к выводу, что мой диск умирает, что RAID-1 правильно с ним справляется и что пришло время заказывать запасной диск. Я заказал новый диск.

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

В этот момент мне было любопытно посмотреть, были ли поврежденные сектора только в незанятых частях диска, я вынул диск из RAID, вставил его обратно в RAID и позволил завершить полную повторную синхронизацию. Повторная синхронизация завершена без ошибок, 9 часов спустя (2TB дисков занимает немного времени).

Кроме того, вывод smartctl немного изменился, как показано ниже:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Итак, часть этого, которая меня извращает, это, конечно, «С каких это пор плохие диски исправляются?»

Я предполагаю, что вполне возможно, что очень маленькая область накопителя спонтанно испортилась, и что накопителю потребовалось 3 дня (!), Прежде чем включился его код перераспределения секторов, и он отобразил несколько свободных секторов поверх поврежденной области диска ... Но я не могу сказать, что я когда-либо видел, чтобы это случилось.

Кто-нибудь еще видел такое поведение? Если да, то каков был ваш опыт вождения после? Это случилось снова? Диск в итоге полностью вышел из строя? Или это просто необъяснимый сбой, который остался необъяснимым?

В моем случае у меня уже есть запасной диск (приобретается по гарантии), поэтому я все равно просто заменю диск. Но я бы хотел знать, не ошибся ли я как-то. Если это помогает, у меня есть полный вывод 'smartctl -a' с момента возникновения проблемы. Это просто немного долго, поэтому я не разместил это здесь.

Если одна конкретная физическая область поверхности диска выходит из строя, то до тех пор, пока эти сектора не будут успешно отображены, вы будете получать невосстановленные ошибки чтения при попытке прочитать любые данные, которые были записаны в эту область. Диск знает, что сектора повреждены (после сбоев доступа к секторам), но не может переназначить сектора, потому что они уже содержат данные. Если вы отформатируете диск или перезапишите «плохие» сектора, то у диска будет возможность отобразить плохие сектора.

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

Я не знаю достаточно о моделях сбоев накопителей в современных накопителях, чтобы понять, существует ли значительная корреляция между ухудшением состояния одной части носителя и распространением или повторением проблемы. Если корреляции нет, то после того, как плохие сектора будут намечены, вы в хорошей форме. Если есть корреляция, то это начало конца для привода.

Большинство современных накопителей «выбрасывают» блок, который вышел из строя. На диске есть пул запасных блоков, и микропрограмма использует их для замены любых блоков, для которых известно, что диск неисправен. Привод не может сделать это повторное сопоставление, когда он не может прочитать блок, потому что он не может предоставить правильные данные. Он просто возвращает «ошибка чтения». Он помечает блок как плохой, поэтому, если блок когда-либо правильно прочитал, тогда блок выворачивается и правильные данные записываются в блок замены. Если операционная система когда-либо ЗАПИСЫВАЕТСЯ в блок, который находится в состоянии «ожидание выхода из вектора», то этот блок удаляется, и данные записываются в блок замены.

После получения ошибки чтения с устройства raid программного обеспечения Linux получит правильные данные из других элементов массива, а затем снова попытается ЗАПИСАТЬ поврежденный блок. Итак, если запись работает нормально, тогда данные в безопасности, если нет, то привод просто выполняет вышеописанное, направляет вектор в блок и затем выполняет запись. Итак, привод с помощью рейд-системы только что восстановился!

Предполагая, что такие события достаточно редки, вероятно, безопасно продолжать. Если используется слишком много сменных блоков, возможно, возникла проблема с приводом. Существует ограничение на количество заменяемых блоков для запасных блоков, и это является функцией привода.

Да, я видел это и при очень похожих обстоятельствах. В моем случае это был «зеленый» накопитель Western Digital емкостью 1 ТБ «WD10EARS» потребительского уровня, который потянул меня на этот трюк. Current_Pending_SectorНеобработанное значение SMART изменилось с нуля до 6, а затем до 8, что побудило демона мониторинга SMART отправить мне несколько зловещих писем.

Я mdadm --failэд и --removed диск из массива и побежал неразрушающий проход badblocksнад ним, и да, были , по- видимому более 2 десятков плохих блоков. Когда сменный диск появился примерно через день, я починил массив, и жизнь пошла дальше.

Вскоре после этого, из-за скуки, я снова включил badblocks«провальный» диск, чтобы посмотреть, ухудшился ли он. Напротив, диск полностью "отремонтировал" себя: ноль плохих блоков! Покачав головой, я вытер ее и отложил для повторного использования или пожертвования.

Урок: не используйте накопители потребительского уровня на серверах, если вы не готовы и не способны мириться со всевозможными странностями и ненадежностью. Следствие: не экономьте на серверных компонентах, потому что в конечном итоге вы в конечном итоге заплатите за них, в дополнительное время и обострение.

В серверных средах обычной практикой является удаление дисков, которые когда-либо показывали такие ошибки, исправленные или нет. Секторные грубые ошибки могут быть признаком физического повреждения поверхности среды - и если вы царапаете поверхность, вы обычно либо смещаете материал по сторонам царапины и получаете заусенцы выше плоскости такой поверхности - либо абразивная пыль (стекло! ). Обе имеют тенденцию быть довольно разрушительными для механической системы, которая опирается на очень тонкую воздушную подушку между двумя поверхностями, которые считаются идеально гладкими ... поэтому средние ошибки, когда они начинают достигать определенного значения, имеют тенденцию к более быстрому размножению.