Я только что обнаружил ту же проблему на двух совершенно новых и идентичных серверах, установленных всего около 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 ГБ 10K RPM VelociRaptor, поэтому я думаю, что они уже синхронизировались. Попытка повторного добавления говорит, что устройство занято:
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 поглотили все:
[ 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 на запасном диске в рейд-наборе?»
решение1
Я не совсем понимаю, заменили ли вы на самом деле неисправный диск(и)? Потому что ваши симптомы были бы понятны мне, если бы вы повторно добавили неисправный диск, в этом случае есть большая вероятность, что диск заблокирован. Если вы действительно повторно добавили неисправный диск, есть ли последующие ошибки в /var/log/messages или dmesg?
(Кстати, я настоятельно не рекомендую когда-либо повторно добавлять неисправный диск в 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.
Первая строка сообщает, что произошел сбой перераспределения, и данные не были прочитаны. Следующие три строки указывают на то, что данные не могут быть прочитаны, и перечисляют сектора, которые не могут быть прочитаны.
Как указал Роджер, диск плохой, не добавляйте его снова. Никогда не стоит повторно добавлять диск, который вышел из строя. Вытащите диск и замените его. Если хотите, запустите диагностику неисправного диска, но только после того, как он будет извлечен и заменен.
решение3
Первое — да, избавьтесь от любого диска, который выдает ошибки чтения, которые попадают в файл журнала. Это означает, что перемещение плохих блоков не удалось и/или диск близок к смерти.
Я предлагаю для восстановления ваших данных использовать загрузочный компакт-диск Linux, напримерhttp://ubuntu-rescue-remix.org/использовать ddrescue. Это может сделать копию образа на новый раздел диска и будет делать много повторных попыток и т. д., чтобы попытаться восстановить ваш раздел. Смонтировать USB-накопитель или другой раздел
mkdir /tmp/x && монтировать /dev/sdd1 /tmp/x
для сохранения файла журнала ddrescue — затем вы можете остановить ddrescue (ctrl-C) и перезапустить его позже с той же точки.
Сделайте раздел на новом диске немного больше старого. Вам не обязательно использовать весь диск!
Загрузите спасательный CD с "nodmraid" в качестве параметра загрузки ядра. Если используете Ubuntu Live CD, установите RAID и LVM, если вы его используете
apt-get install mdadm lvm2 gddrescue
вам понадобится подключение к интернету, чтобы это сработало). В противном случае используйте ubuntu rescue CD для шага ddrescue. Я переключался между rescue CD для запуска ddrescue и live CD для работы 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/logfile
затем
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
затем
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
Не бойтесь нажать Ctrl-C, если восстановление одного сектора занимает несколько часов. Просто переходите к следующему шагу (шаг 1 должен быть успешным в любом случае). Последний шаг пытается восстановить последние крохи пригодных для использования данных.
Вам также придется сделать
mdadm --create /dev/md99 --level-1 --raid-devices=2 отсутствует /dev/sdX
чтобы создать новый RAID-массив с использованием нового диска, на разделе записывается новый суперблок RAID (в последние 64–128 КБ в конце раздела).
Удалите старый неисправный диск /dev/sdb из системы, чтобы он не был виден Linux.
Сделайте свой исходный диск RAID доступным. Возможно, вам придется использовать параметр "nodmraid" для загрузки ядра, так как у меня были проблемы с ubuntu rescue CD, и в итоге я использовал Ubuntu live CD (10.4), где nodmraid находится в параметрах F6. Вам просто нужно использовать
mdadm --assemble /dev/md99 /dev/sdX
Затем выполните fsck или любую другую проверку, которую вам нужно выполнить для данных на RAID-массиве md99 (я использовал vgscan, после чего смог увидеть логические тома LVM, по которым можно было выполнить проверку). Я использую XFS для mythtv, но команда 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/boot/grub /dev/sdX
теперь у вас есть (почти) загрузочный RAID-массив. Вы также можете выполнить настройку с помощью самого GRUB или использовать dd для копирования первых 446 байт /dev/sdb в /dev/sdX. ТОЛЬКО первые 446 байт, остальная часть 1-го сектора — это ваша таблица разделов, которую вы сильно забьете, если скопируете больше! Вам также, возможно, придется сделать то же самое для 1-го сектора в вашем разделе /dev/sdX1 (скажем). Сделайте резервную копию всех секторов, которые вы собираетесь перезаписать, также с помощью dd.
Если вы используете grub2 и загружаетесь с RAID, вы обнаружите, что UUID RAID-массива изменился, поэтому загрузка невозможна. Отредактируйте командную строку загрузки (e на панели запуска Grub), чтобы удалить splash и quiet, чтобы вы могли видеть, что происходит. Затем после неудачной загрузки вы остаетесь в initramfs.
mdadm --assemble /dev/md99 /dev/sdX
затем проверьте /proc/mdstat, чтобы убедиться, что массив там есть. Если он там есть, то просто "выйдите" и, надеюсь, ваша загрузочная строфа GRUB будет работать нормально (моя была настроена на использование LVM, поэтому она просто нашла LV на устройстве RAID, как только там было какое-либо устройство RAID, она просто искала LV). После загрузки вы почти закончили.
Файл образа initrd (cpio-файл, сжатый gzip) содержит копию 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 ТБ.
Уф! Готово!