Я только что обнаружил ту же проблему на двух совершенно новых и идентичных серверах, установленных всего около 9 месяцев назад. Мне не удалось записать на диск на них обоих, потому что система пометила его как доступный только для чтения. Журналы показали, что на обоих была какая-то ошибка диска.
Обратите внимание, что я использую KVM с несколькими гостями на каждом из этих серверов. Все гости работали нормально, но проблема была в хосте KVM. Это, вероятно, не имеет значения, но, возможно, имеет отношение. Обе системы имеют только два диска с программным raid1 и LVM поверх. У каждого гостя KVM также есть свой собственный раздел LVM.
Обе системы демонстрировали ухудшенный массив RAID1 при просмотре /proc/mdstat.
Итак, я перезагрузил одну из систем, и она сказала мне, что мне нужно вручную запустить fsck. Я так и сделал. Похоже, что проблемы были устранены, и после перезагрузки система вернулась в нормальное состояние. Тот же процесс работал и на втором сервере.
Далее я побежал mdadm --manage /dev/md0 --add /dev/sdb1 для добавления отказавшего диска обратно в массив. Это нормально работало на обоих серверах. В течение следующего часа или около того, глядя на /proc/mdstat показал прогресс в синхронизации дисков. Примерно через час одна система завершила работу и /proc/mdstat показал, что все прекрасно работает с [UU].
Однако в другой системе примерно через 1,5 часа загрузка системы резко возросла, и ничего не реагировало. Через несколько минут все вернулось. Но глядя на /proc/mdstat теперь показывает следующее:
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
Как видите, похоже, он больше не синхронизируется. Процент выполнения, оставшееся время и т. Д. Больше не отображается. Однако бег mdadm --detail /dev/md0 показывает это:
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
Нижняя строка, кажется, указывает на то, что запасная часть восстанавливается. Почему запасной? Система сообщает об обоих устройствах как о чистых. Так оставалось несколько часов. Диски маленькие и быстрые, 300 ГБ, 10 000 об / мин VelociRaptors, так что я думаю, что они уже синхронизировались. При повторном добавлении устройство занято:
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
Запуск dmesg на "хорошем" сервере показывает это в конце:
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
На «плохом» сервере эти последние 4 строки повторяются сотни раз. На «хорошем» сервере они показываются только один раз.
Диски все еще синхронизируются? Закончится ли эта «перестройка»? Мне просто нужно быть более терпеливым? Если нет, что мне теперь делать?
ОБНОВИТЬ:
Я только что перезагрузился, и диск снова начал синхронизироваться. Спустя почти 2 часа произошло то же самое, что описано выше (все равно [_U]). Однако я смог увидеть журналы dmesg до того, как фрагменты распечатки RAID1 conf поглотили все это:
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
Так что, возможно, мне стоит задать вопрос: «Как запустить fsck на запасном диске в наборе рейдов?»
Мне неясно, действительно ли вы заменили неисправный диск (и)? Потому что ваши симптомы имели бы смысл для меня, если бы вы повторно добавили неисправный диск, и в этом случае есть большая вероятность, что диск заблокирован. Если вы повторно добавили неисправный диск, возникнут ли последующие ошибки в / var / log / messages или dmesg?
(Между прочим, я настоятельно рекомендую никогда не добавлять неисправный диск в массив RAID. Если сбой повредил данные на пластине, вы можете обнаружить, что при добавлении его обратно в массив повторная синхронизация оставляет поврежденный файл на диске. диска, и в следующий раз, когда вы будете читать файлы, вам будет нелегко определить, получите ли вы хорошие или плохие данные, в зависимости от того, какой диск откликается первым; я видел, как это происходило на практике.)
Во-первых, да, избавьтесь от любого диска, который выдает ошибки чтения, которые попадают в файл журнала. Это означает, что перемещение поврежденного блока завершилось неудачно и / или диск близок к смерти.
Я предлагаю для спасения ваших данных использовать аварийный компакт-диск Linux, например http://ubuntu-rescue-remix.org/ использовать ddrescue. Это может сделать копию образа на новый раздел диска и будет делать много попыток и т.д., чтобы попытаться восстановить ваш раздел. Смонтируйте USB-накопитель или другой раздел
mkdir / tmp / x && mount / dev / sdd1 / tmp / x
чтобы сохранить файл журнала ddrescue - тогда вы можете остановить ddrescue (ctrl-C) и перезапустить его позже с той же точки.
Сделайте раздел на новом диске немного больше, чем на старом. Необязательно использовать весь диск!
Загрузите аварийный компакт-диск с «nodmraid» в качестве параметра загрузки ядра. Если вы используете live CD Ubuntu, установите RAID и LVM, если вы их используете.
apt-get install mdadm lvm2 gddrescue
вам нужно будет быть в Интернете, чтобы это работало). В противном случае используйте аварийный компакт-диск ubuntu для шага ddrescue. Я поменял местами аварийный компакт-диск для запуска ddrescue и live-компакт-диск для работы с grub и fsck.
Предположим, что / dev / sdb - это ваш отказавший исходный диск, а / dev / sdx - ваш новый диск, а / mnt / x - USB-ключ или раздел на другом смонтированном диске. Вы необходимость файл журнала ddrescue, правда! Поскольку он отслеживает, как идет ddrescue, и позволяет его прервать.
Согласно http://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split / dev / sdb / dev / sdX файл образа / mnt / x / файл журнала
затем
ddrescue --direct --max-retries = 3 / dev / sdb / dev / sdX / mnt / x / файл журнала
затем
ddrescue --direct --retrim --max-retries = 3 / dev / sdb / dev / sdX / mnt / x / файл журнала
Не бойтесь нажимать Ctrl-C, если восстановление одного сектора занимает несколько часов. Просто переходите к следующему шагу (шаг 1 должен быть успешным, несмотря ни на что). Последний шаг пытается восстановить последние крохи пригодных для использования данных.
Вам также нужно будет сделать
mdadm --create / dev / md99 --level-1 --raid-devices = 2 отсутствует / dev / sdX
чтобы создать новый массив RAID с использованием нового диска, он записывает новый суперблок RAID в разделе (в последних 64 КБ до 128 КБ в конце раздела).
Удалите старый неисправный диск / dev / sdb из системы, чтобы он не был виден Linux.
Сделайте ваш исходный диск RAID доступным. Возможно, вам придется использовать параметр «nodmraid» для ядра, загружающего ядро, поскольку у меня были проблемы с аварийным компакт-диском ubuntu, и в итоге я использовал Live CD Ubuntu (10.4), где nodmraid находится в параметрах F6. Вам просто нужно использовать
mdadm --assemble / dev / md99 / dev / sdX
Затем fsck или выполните любую необходимую проверку данных в массиве RAID md99 (я использовал vgscan, после чего смог увидеть LVM LV, чтобы выполнить проверку). Я использую XFS для migtv, но команда xfs_check вызвала сбой моей системы, но xfs_repair был в порядке.
Смонтируйте каталог / boot из вашего нового / dev / sdX
смонтировать / dev / mapper / my_vg / root_lv / tmp / x
затем поместите новую загрузочную запись GRUB на новый диск RAID / dev / sdX (только если вы загружаетесь с RAID!)
grub-setup -d / tmp / x / загрузка / grub / dev / sdX
теперь у вас есть (почти) загрузочный RAID-массив. Вы также можете выполнить настройку с помощью самого GRUB или использовать dd для копирования первых 446 байтов / dev / sdb в / dev / sdX. ТОЛЬКО первые 446 байтов, остальная часть 1-го сектора - это ваша таблица разделов, которую вы сильно заполните, если скопируете больше! Возможно, вам также придется сделать то же самое для 1-го сектора в вашем разделе / dev / sdX1 (скажем). Сделайте резервную копию любых секторов, которые вы собираетесь перезаписать, также используя dd.
Если вы используете grub2 и загружаетесь с RAID, вы обнаружите, что UUID RAID-массива изменился, поэтому загрузка не удастся. Отредактируйте командную строку загрузки (e на панели запуска Grub), чтобы удалить всплеск и тишину, чтобы вы могли видеть, что происходит. Затем после неудачной загрузки вы останетесь в initramfs.
mdadm --assemble / dev / md99 / dev / sdX
затем проверьте / proc / mdstat, чтобы убедиться, что массив есть. Если это просто «выход», и, надеюсь, ваша загрузочная строфа GRUB будет работать нормально (моя была настроена на использование LVM, поэтому он просто нашел LV на устройстве RAID, когда там было какое-либо устройство RAID, он просто искал LV). Как только вы загрузитесь, вы почти закончили.
Файл образа initrd (gzip-файл cpio) содержит копию mdadm.conf, используемую во время процесса загрузки, видимую и редактируемую как /etc/mdadm/mdamdm.conf во время процесса загрузки. Если вы можете нормально загрузить свою систему, просто обновите initramfs, используя
обновление-initramfs -u
Если вы не можете загрузить систему из-за несоответствия UUID в файле mdadm.conf
Имейте в виду, что ваше целевое устройство / dev / sdX может отображаться как / dev / sdY при загрузке другим способом (Grub, rescue, real boot).
Кстати, если вы не используете RAID5 и действительно не заинтересованы в выравнивании блоков, я бы использовал раздел для вашего RAID-массива, вам не нужно использовать весь диск (особенно, если вы заменяете диск 1 ТБ на 2 ТБ один). Вы всегда можете добавить еще один раздел и второй RAID-массив позже, чтобы использовать все 2 ТБ.
Фух! Готово!
Использование mdadm --details отобразит диск как запасной на время восстановления. После завершения восстановления он больше не будет отображаться как запасной.
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
В первой строке указано, что произошел сбой перераспределения и данные не были прочитаны. Следующие три строки указывают на то, что данные не могут быть прочитаны, и перечисляют сектора, которые не читаются.
Как указал Роджер, диск неисправен, не добавляйте его повторно. Никогда не рекомендуется повторно добавлять неисправный диск. Вытащите привод и замените его. Если хотите, запустите диагностику неисправного диска, но только после того, как он был извлечен и заменен.