Я столкнулся с некоторыми странными ошибками на некоторых жестких дисках, и мне трудно сузить проблему. Это часть RAID-массива (программный RAID-массив Linux, бюджетное оборудование), поэтому, когда он выпал из массива, моей первой реакцией было просто заменить его запасным. Но восстановление продолжало терпеть неудачу.
Диски находятся в 5-дисковом внешнем корпусе SATA (4 корпуса по 5 дисков в каждом), и я заметил, что этот корпус также демонстрирует странные симптомы. Обычно, когда диск добавлен, индикаторы мигают определенным образом, поскольку репликатор портов SATA корпуса обнаруживает новый диск. И это продолжало происходить во время перестройки, что намекало мне на то, что, возможно, аппаратное обеспечение репликатора портов было настоящим виновником.
У меня есть запасной корпус для такой проблемы, поэтому я поменял его и вставил диски в новый. Но в этот момент mdadm
не смог восстановить диск вообще. Это всегда терпело неудачу сразу после запуска. Я попробовал пару разных запасных дисков, один и тот же симптом. Конечно, у меня не было нескольких дисков, которые выходили из строя одинаково в одно и то же время?
Корпуса подключаются к 2 платам контроллера SATA, установленным на хосте, по 2 порта каждая. Может быть, это была одна из карточек? Поэтому я передвигался по кабелям SATA, чтобы "оскорбительный" корпус находился на другой плате. Но та же проблема с тем же отсеком для диска в том же корпусе сохраняется.
На данный момент у меня заканчиваются вещи для тестирования. У меня есть 2 диска, 2 корпуса и 2 платы контроллера на хосте. Любая их комбинация создает те же проблемы.
На данный момент mdadm
пытается восстановить накопитель (не уверен, почему на этот раз он не вышел из строя), но со значительно сниженной скоростью. Он колеблется между 1/2 и 1/4 нормальной скорости. Сменный корпус также повторно обнаруживает диск, как и предыдущий.
Я не очень разбираюсь в диагностике оборудования. С товарным оборудованием это обычно цикл замены. Но в этом случае все запасные части ведут себя одинаково, поэтому я не уверен, в чем проблема. Я гуглил некоторые вещи, которые вижу в /var/log/syslog
но до сих пор почти ничего не понял. Я могу сказать вам, что ...
Когда корпус «повторно обнаруживает» диск, это отображается в syslog
:
Oct 3 17:43:52 gibson kernel: [ 1478.755088] ata5: controller in dubious state, performing PORT_RST
Oct 3 17:43:54 gibson kernel: [ 1480.909415] ata5.05: limiting SATA link speed to 1.5 Gbps
Другие тревожные и часто повторяющиеся сообщения в syslog
выглядят так:
Oct 3 17:46:05 gibson kernel: [ 1612.163891] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x6
Oct 3 17:46:05 gibson kernel: [ 1612.163894] ata5.00: irq_stat 0x00060002, device error via D2H FIS
Oct 3 17:46:05 gibson kernel: [ 1612.163897] ata5.00: SError: { Handshk }
Oct 3 17:46:05 gibson kernel: [ 1612.163899] ata5.00: failed command: WRITE DMA
Oct 3 17:46:05 gibson kernel: [ 1612.163904] ata5.00: cmd ca/00:00:00:29:87/00:00:00:00:00/e0 tag 0 dma 131072 out
Oct 3 17:46:05 gibson kernel: [ 1612.163905] res 51/84:90:70:29:87/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
Oct 3 17:46:05 gibson kernel: [ 1612.163907] ata5.00: status: { DRDY ERR }
Oct 3 17:46:05 gibson kernel: [ 1612.163909] ata5.00: error: { ICRC ABRT }
и иногда это:
Oct 3 18:07:10 gibson kernel: [ 2877.073010] ata5.00: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073015] ata5.00: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073017] ata5.01: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073020] ata5.01: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073022] ata5.02: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073024] ata5.02: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073026] ata5.03: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073028] ata5.03: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073030] ata5.04: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073032] ata5.04: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073034] ata5.05: failed to read SCR 1 (Emask=0x40)
Могу ли я выполнить другие тесты? Другие вещи, которые я могу попробовать? Что может быть не так, что вызывает симптомы, независимо от используемого оборудования?
Массив работал отлично в течение многих лет, со случайной заменой диска. На хосте не было внесено никаких изменений программного обеспечения (если я не был скомпрометирован и не знаю этого, что, безусловно, возможно). Но отказ диска несколько месяцев назад привел к постоянному восстановлению и в конечном итоге оставил меня в текущем состоянии.
Изменить: еще один шаблон, который я только что понял, не уверен, что это что-то значит. Диски в массиве от sdb1
до sdu1
. Они не всегда видны загрузочной ОС в одном и том же порядке, поэтому любой диск может изменить свою букву при перезагрузке. Когда накопитель постоянно отказывал сразу после восстановления mdadm
, это был /dev/sdq1
. Но на всем протяжении текущих симптомов (медленная перестройка, «переобнаружение» корпуса снова и снова, и в основном ошибки, зарегистрированные выше), это было /dev/sdu1
.
Редактировать: я скачал Knoppix 7.2, чтобы посмотреть, смогу ли я запустить массив и добавить туда диск. Просто чтобы посмотреть, может быть, это проблема программного обеспечения. Точно такие же симптомы. Итак ... было заменено оборудование, программное обеспечение было заменено, но проблема сохраняется. Это оставляет меня в тупике на данный момент.
Изменить: я также попытался просто обнулить диск с этим:
dd if=/dev/zero of=/dev/sdu bs=1M
Но те же симптомы сохраняются. На данный момент я подозреваю, что, возможно, что-то не так с контроллером, но в некотором смысле я не понимаю. Каждая из двух карт работает, но по какой-то причине обе вместе не могут управлять таким количеством дисков? Не имеет никакого смысла, я просто пытаюсь определить здесь закономерности.
Редактировать: Вывод smartctl -a -d ata /dev/sdu
:
smartctl 5.40 2010-10-16 r3189 [x86_64-slackware-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green family
Device Model: WDC WD20EADS-00S2B0
Serial Number: WD-WCAVY0536607
Firmware Version: 01.00A01
User Capacity: 2,000,398,934,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Oct 5 07:04:21 2013 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (42900) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 179 179 051 Pre-fail Always - 90370
3 Spin_Up_Time 0x0027 149 149 021 Pre-fail Always - 9525
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6170
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 18
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 9
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 610025
194 Temperature_Celsius 0x0022 117 073 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 125
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 62927
200 Multi_Zone_Error_Rate 0x0008 090 090 000 Old_age Offline - 22176
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Обновление: у меня может быть мой первый многообещающий разрыв в этом каперсе. Потратив последние 6 или около того часов (вкл. И выкл.) На замену дисков / корпусов / кабелей / карт и систематически пытаясь найти шаблон, я наконец нашел его. И тот, который я могу последовательно воспроизводить.
Он не любит горячую замену.
Это говорит, что делает. Это подразумевает. И он делает все возможное, чтобы сдержать это обещание. Но это ложь. Я не буду притворяться, что знаю что-либо об архитектуре аппаратного обеспечения низкого уровня и / или архитектуре ядра, которая играет в этом роль, но я могу, по крайней мере, логически определить воспроизводимый шаблон.
Бьюсь об заклад, я начал горячую замену этим летом, даже не осознавая этого, и, вероятно, в результате вызвал весь этот беспорядок. syslog
показывает, что ошибки, которые я видел, начались в июне, незадолго до того, как произошел серьезный сбой, и как раз перед тем, как я поехал в SF летом и не мог над этим поработать.
Но если я перезагружаюсь в любое время, мне нужно переместить диск, так что пока я не вижу ошибок. 20-й диск был заново добавлен и восстанавливается с правильной скоростью (что все еще занимает около 36 часов для диска объемом 2 ТБ), и я наблюдаю (tail -f
) syslog
который до сих пор был тихим.
Пройдет несколько дней, прежде чем я смогу сообщить об этом с уверенностью. Но пока это выглядит многообещающе. Ответом на это может стать то, что «не делайте горячую замену с Rosewill RSV-S5 в Linux», скрестив пальцы.