Прошу помощи сообщества. Есть линуксовый сервер на хецнере — с двумя SATA дисками, объединёнными в зеркало (RAID 1) при помощи mdadm. Вылетел один из дисков. После замены, пробую сделать ребилд массива. Ребилдятся все разделы кроме одного — новый диск упорно встаёт как SPARE. Это выглядит следующим образом:
=========
cat /proc/mdstat
Personalities: [raid1]
md0: active raid1 sda1[2] sdb1[1]
33553336 blocks super 1.0 [2/2] [UU]
md1: active raid1 sda2[2] sdb2[1]
524276 blocks super 1.0 [2/2] [UU]
md127: active raid1 sda5[2](S) sdb5[0]
2110014324 blocks super 1.0 [2/1] [U_]
=========
Ни гугление, ни танцы с бубном и ключами mdadm результата не достигли.
Господа и дамы, подскажите пожалуйста, как всё-таки сделать sda5 полноценным членом рейда?
Если на единственной активной реплике есть ошибки чтения, репликация с неё будет постоянно перезапускаться и обрываться на первой ошибке, а второй диск будет постоянно считаться spare.
Решал именно такую проблему. Мы вычислили адрес сектора, на котором ошибка, принудительно ремапили его с помощью hdparm и тогда репликация завершилась успешно. (Я тут даже вопрос задавал — как hdparm обрабатвает advanced format диски? Оказалось, правильно обрабатывает, зачищает все восемь секторов.)
А напишите, пожалуйста, команды которыми пользовались и ссылку на свой вопрос дайте. Те, кто забредут в вопрос из поисковиков будут иметь решение в одном месте.
В тексте ниже сбойный оригинал — sdb, spare — sda.
Информацию о массиве смотреть так: mdadm --detail /dev/md2 (в mdstat маловато интересного)
Анализ партиций в parted (универсальное решение, поэтому он):
unit b
select /dev/sda
print
select /dev/sdb
print
Собственнно таблица выглядит так:
Number Start End Size File system Name Flags
…
3 34898706432B 1134410334207B 1099511627776B raid
…
(3 -как раз та партиция, которая не синкается)
Заодно мы убеждаемся, что партиции на дисках точно одинаковые по размеру (unit b говорит «показывай в байтах»; можно ещё настроить показ в секторах).
dmesg подобный:
… kernel: [71238.737802] sd 1:0:0:0: [sdb] Unhandled sense code
… kernel: [71238.737828] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
… kernel: [71238.737860] sd 1:0:0:0: [sdb] Sense Key: Medium Error [current] [descriptor]
… kernel: [71238.739405] Descriptor sense data with sense descriptors (in hex):
… kernel: [71238.739434] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
… kernel: [71238.739478] 43 d8 23 98
… kernel: [71238.739504] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error — auto reallocate failed
… kernel: [71238.739554] sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 43 d8 23 98 00 00 08 00
… kernel: [71238.739639] ata2: EH complete
… kernel: [71238.833501] md: md2: recovery done.
причём на самом деле нисколько он не done
Так мы находим сбойный сектор:
dd if=/dev/sdb of=/dev/null
и ждём обрыва, наблюдая за результатом. Можно партицию сразу if=/dev/sdb3.
вот программа выдала номер сбойного сектора. Это номер относительно начала партиции:
dd: reading `/dev/sdb3': Input/output error
1159470544+0 records in
1159470544+0 records out
593648918528 bytes (594 GB) copied, 4664.35 s, 127 MB/s
bs по умолчанию 512 байтов, поэтому это сектор. Номер LBA от начала диска рассчитывается легко.
Длина раздела — 1099511627776 — ровно терабайт в моём случае. Начало — 34898706432 байт. Номер сектора от начала раздела — 1159470544.
LBA виртуального сектора (у нас advanced format) рассчитывается так: 34898706432/512+1159470544 = 1227632080
Проверяем: hdparm --read-sector 1227632080 — оказался живой! Зато ...79 — мёртвый, и вообще все восемь — 78, 77,… — мёртвые (весь физический сектор).
Итак, молотком hdparmа по секторам 1227632072..1227632079.
(команда искажена специально, чтобы не выполнилась — может уничтожить данные!)
hdparm –write-sector 1227632072 /dev/sdb –no-i-dont-know-what-i-am-doing
Программа сама поймёт, что нужно убить все восемь (смотрели исходники).
hdparm --read-sector 1227632072 /dev/sdb не работал, а теперь работает! А в smart появилась реаллокация. И синк прошёл до конца.
Ну, а после этого настоятельно советую запустить check (echo «check» > /sys/block/md2/md/sync_action, мог спутать путь, проверьте). Для всех массивов. После этого вероятно стоит поменять теперь внезапно сбойный диск.
Простите за сумбур! Я частично восстанавливал по памяти, частично по логам чата (отсюда номера), не все команды сохранились — досочинял. Должно быть правильно.
О, вопрос про AF был, но я оказывается перепутал — он по поводу mhdd. По поводу hdparm не было — говорю же, нашли ответ в исходниках, чего спрашивать? Ссылки не будет, она нерелевантна. (Если кому-то интересно, идите в мой профиль, там «его» и «q&a» — сами увидите.)
Можно и топик, если будет полноценное руководство по выявлению и устранению ошибок step-by-step. В рунете мало статей по этой теме, лишним не станет. Если обладаете информацией о поддержке различных raid на уровне ФС, то это ещё одна полноценная статья (для многих, я не исключение, разнесение логики на несколько прослоек — тёмных лес и тонны нелопаченых исходников). Буду очень благодарен!
Удалить, добавить, ждать синхронизации. Просите замену, сохраните логи. Сегодня утром баловался, отвечая на этот вопрос (посмотрите, может что-то полезным будет). Посмотрите документацию по сбоям.
Если сделать подобным образом, то новый диск 100% встанет как spare. Возможно это потому, что исходный диск, тоже начал сыпаться? SMART находит там OfflineUncorrectableSector.
Спасибо за подсказку. Не копали в эту сторону. mdadm ругается, что опция -x не совместима с режимом grow. Надо поискать варианты применения этой опции.
Проверить не на чем сейчас, но ман говорит, что -x именно для grow. Возможно, другая версия?
В крайнем случае, я бы просто пересобрал рейд, с правильными -x и -n.
