Моя история начинается довольно просто. У меня есть легкий сервер под управлением 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
Оглядываясь назад в журналах, я обнаружил, что ошибки действительно происходили в течение нескольких дней, в основном во время резервного копирования, но также часто при очень легком использовании (то есть примерно каждый 5-й раз, когда я пытался сохранить текстовый файл). Я пришел к выводу, что мой диск умирает, что RAID-1 правильно с ним обращается и что пришло время заказать диск на замену. Заказал новый диск.
К моему большому удивлению, через день ошибки ... прекратились. Я ничего не сделал, чтобы их исправить. Я не перезагружался, не отключал привод, ничего. Но ошибки просто прекратились.
В этот момент мне было любопытно узнать, находятся ли теперь поврежденные сектора только в незанятых частях диска, поэтому я вынул диск из RAID, вставил его обратно в RAID и позволил ему завершить последующую полную повторную синхронизацию. Повторная синхронизация завершилась без ошибок через 9 часов (для дисков емкостью 2 ТБ требуется немного времени).
Кроме того, вывод 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» с момента возникновения проблемы. Это немного длинновато, поэтому я не публиковал его здесь.
Если одна конкретная физическая область поверхности диска выходит из строя, то до тех пор, пока эти секторы не будут успешно сопоставлены, вы получите неисправленные ошибки чтения, когда попытаетесь прочитать любые данные, которые были записаны в эту область. Диск знает, что секторы повреждены (после сбоев доступа к секторам), но не может переназначить сектора, потому что они уже содержат данные. Если вы отформатируете диск или перезапишите «плохие» сектора, то у диска будет возможность отобразить поврежденные сектора.
После того, как поврежденные секторы нанесены на карту, и пока большая часть поверхности диска не выйдет из строя, вы в хорошей форме.
Я не знаю достаточно о моделях отказа существующих приводов, чтобы знать, есть ли большая корреляция между ухудшением состояния одной части поверхности носителя и распространением проблемы или ее повторным появлением. Если корреляции нет, то, как только поврежденные сектора будут нанесены на карту, вы в хорошей форме. Если здесь является корреляция, то это начало конца драйва.
Большинство современных приводов будут "векторить" поврежденный блок. У диска есть пул запасных блоков, и микропрограмма использует их для замены любых блоков, о которых известно, что диск неисправен. Привод не может выполнить это повторное отображение, когда он не может ПРОЧИТАТЬ блок, потому что он не может предоставить правильные данные. Он просто возвращает «ошибку чтения». Он помечает блок как плохой, поэтому, если блок когда-либо читается правильно, блок удаляется, и правильные данные записываются в блок замены. Если ОС когда-либо ЗАПИСЫВАЕТ в блок, который находится в состоянии «ожидания вывода вектора», тогда блок удаляется, а данные записываются в блок замены.
Рейд программного обеспечения Linux при получении ошибки чтения от устройства получит правильные данные от других элементов в массиве, а затем снова попытается ЗАПИСАТЬ плохой блок. Итак, если запись работает нормально, то данные в безопасности, если нет, диск просто выполняет вышеуказанное, осуществляет векторную запись блока и затем выполняет запись. Итак, диск с помощью рейдовой системы просто отремонтировал сам себя!
Если предположить, что такие события достаточно редки, то, вероятно, будет безопасно продолжать. Если используется слишком много сменных блоков, возможно, неисправен привод. Существует ограничение на количество заменяемых блоков, которые можно направить в резервные блоки, и это функция привода.
Да, я тоже это видел, и при очень похожих обстоятельствах. В моем случае это был «зеленый» накопитель Western Digital емкостью 1 ТБ (WD10EARS) потребительского уровня, который меня натворил. SMART Current_Pending_Sector исходное значение изменилось с нуля до 6, а затем до 8, что побудило демон мониторинга SMART прислать мне несколько зловещих писем.
я mdadm --failЭд и --removed диск из массива и выполнил неразрушающий проход badblocks над ним, и да, по-видимому, было более двух десятков плохих блоков. Когда примерно через день пришел новый диск, я починил массив, и жизнь продолжалась.
Вскоре после этого я от скуки переиграл badblocks на «неудавшемся» диске, чтобы увидеть, не ухудшилось ли оно. Напротив, накопитель полностью «отремонтировал» себя: ноль плохих блоков! Покачав головой, я вытер ее и отложил на переработку или в дар.
Урок: не используйте диски потребительского уровня в серверах, если только вы не готовы и не способны мириться со всевозможными странностями и ненадежностью. Следствие: не удешевляйте серверные компоненты, потому что в конечном итоге вы все равно будете за них платить, потратив дополнительное время и из-за проблем.
В серверных средах распространена практика отбрасывать диски, которые когда-либо показывали такие ошибки, исправленные или нет. Сильные ошибки в секторах могут быть признаком физического повреждения поверхности материала - и если вы поцарапаете поверхность, вы обычно либо смещаете материал по сторонам царапины и получаете заусенец выше, чем плоскость такой поверхности, либо абразивная пыль (стекло! ). Оба имеют тенденцию быть довольно разрушительными для механической системы, которая полагается на очень тонкую воздушную подушку между двумя поверхностями, считающимися идеально гладкими ... поэтому средние ошибки, когда они начинают достигать определенного количества, имеют тенденцию увеличиваться гораздо быстрее.