Серьезная проблема RAID, которая пугает систему

Система: Двойной Xeon E5-2630 CPU, 32 ГБ RAM, Первичный диск является SATA-III Решающий SSD на 512 ГБ ОС: Xubuntu 14.04.1

У меня есть серьезная проблема с RAID в этой новой системе и надежде, которую некоторые из Вас могут обеспечить некоторому пониманию. В настоящее время основной SSD с корневой файловой системой не зеркально отражается, хотя я планирую зеркально отразить его к второму идентичному SSD в будущем. Я пытаюсь настроить RAID на вторичном наборе жесткого диска и не желаю обновить основной набор SSD, пока эта проблема не решена.

У меня есть пара дисков SATA-III Seagate ST4000DM0004TB Baracuda 4 ТБ в этой системе, которые были отформатированы тождественно с единственным большим разделом ext4 GPT. Я пытался создать полезное зеркало RAID 1 на этих дисках, которое затем смонтировано на/x. Однажды у меня было что-то, что, казалось, было стабильно и работало в течение нескольких недель, пока я не пытался изменить Массив, в которой точке это перестало работать. Каждый раз зеркальные сбои, это, по-видимому, пугает систему, и корневая файловая система на SSD повторно смонтирована только для чтения согласно установке в/etc/fstab (errors=remount-ro). Конечно, система теперь бесполезна и требует жесткой перезагрузки. Системные перезагрузки, но зеркало теперь полностью повреждаются и должны обычно уничтожаться и восстанавливаться. Я выполнил аппаратную диагностику и не вижу проблемы. Существуют нулевые подсказки относительно что не так в любом из файлов журнала (dmesg, kern.log, системный журнал). Вот некоторые детали:

---

Я создаю Массив следующим образом:

# mdadm --create /dev/md2 --verbose --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdc1 appears to contain an ext2fs file system
    size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device. If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: /dev/sdd1 appears to contain an ext2fs file system
    size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: size set to 3906885440K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Я проверяю прогресс сборки RAID:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[1] sdc1[0]
    3906885440 blocks super 1.2 [2/2] [UU]
    [>....................] resync = 0.4% (17314560/3906885440) finish=415.6min speed=155968K/sec

unused devices: <none>

Я продолжаю периодически контролировать пересинхронизирующую операцию с вышеупомянутой командой, и она проходит без проблемы. Однако в какой-то момент (у меня была пересинхронизация, добираются до где угодно от 4% до синхронизировавших 60%), системная паника и корень повторно смонтирован RO. Когда система перезагружается, я обычно нахожу следующее:

# l /dev/md*
/dev/md127 /dev/md127p1

/dev/md:
dymaxion:2@ dymaxion:2p1@

В случае, где мне действительно удавалось получить созданный/dev/md2 и выполнение, у меня было/dev/md2 и/dev/md2p1 устройства ни с чем в/dev/md подкаталоге. Здесь испуганная система, кажется, пытается спасти массив как md127. Я не понимаю, почему, но это неоднократно происходило. Возможно это - результат некоторого алгоритма, кодированного в mdadm программное обеспечение.

Когда-то массив md127 ухудшается к такой точке, что это не может быть смонтировано во время начальной загрузки (существует запись для массива в/etc/fstab), и другие времена, которые это действительно монтируется и пытается повторно синхронизировать. Однако это часто пугает систему во время этой операции, ведя к непрерывной серии перезагрузок.

Я затем уничтожаю массив и пытаюсь воссоздать его. Это команды, которые я использую для уничтожения его.

# mdadm --stop /dev/md127
mdadm: stopped /dev/md127

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

неиспользованные устройства:

# mdadm -QD /dev/md127
mdadm: cannot open /dev/md127: No such file or directory

# mdadm --zero-superblock /dev/sdc1
# mdadm --zero-superblock /dev/sdd1

Я попытался создать массив в тихой системе без настольных процессов, работающих кроме нескольких окон терминала. Я выполнил комплект тестирования оборудования флажка-gui, и все проверяет прекрасный. Я пытался отключить все другие диски SATA, USB-порты, Картридер, Оптический диск, и т.д. и затем выполнял сборку, и это все еще перестало работать.

Кто-либо может определить некоторую причину, почему массив перестал работать, или предложите некоторый способ лучше определить то, что происходит?

Вот некоторая дополнительная информация о моих усилиях.

Что я делал на своем Сервере Sun (Солярис 10) в течение прошлых 10 лет присоединение третий диск к массиву, позвольте этому синхронизировать, отсоединять его от массива и затем брать его от сайта для аварийного восстановления. Это работало отлично, и это - то, что я запланировал сделать в этой системе Ubuntu.

Используя вышеупомянутые процедуры, мне действительно однажды удавалось получить/dev/md2, правильно созданный с этими двумя внутренними дисками. Система работала без проблемы в течение нескольких недель, таким образом, я был готов присоединить третий диск с помощью отсека замены в горячем режиме. Я перезагрузил с 3-м диском в отсеке замены в горячем режиме. Из-за произвольных переназначений устройства новый диск появился как/dev/sda, и зеркало использовало/dev/sdd и/dev/sde.

# mdadm -QD /dev/md2p1 (or: # mdadm -QD /dev/md2)
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Sep 19 14:02:45 2014
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 129

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1


# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[2] sde1[3]
      3906885440 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Все выглядит хорошим. Давайте добавим/dev/sda1 как запчасть к/dev/md2p1:

# mdadm /dev/md2 --add /dev/sda1

# mdadm -QD /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Oct 17 13:36:13 2014
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 130

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1

         4 8 1 - spare /dev/sda1

Хорошо, давайте присоединим запчасть к массиву с помощью выращивать опции:

# mdadm /dev/md2 --grow -n3

# mdadm -QD /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Oct 17 14:43:08 2014
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 0% complete

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 134

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1
         4 8 1 2 spare rebuilding /dev/sda1

Хорошие взгляды! Позвольте третьему диску синхронизировать:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda1[4] sdd1[2] sde1[3]
      3906885440 blocks super 1.2 [3/2] [UU_]
      [>....................] recovery = 0.7% (27891328/3906885440) finish=376.2min speed=171823K/sec

unused devices: <none>

Где-нибудь после того, как зеркало синхронизировало больше чем 10%, испуганная система. На этот раз, когда система была перезагружена, процесс начальной загрузки не мог повторно прикрепить зеркало к/x и запрошенный повторить или пропустить монтирование. Я пропустил его и когда загруженная система, не было никакого способа повторно активировать/dev/md2. В конечном счете я должен был уничтожить его и запуститься. Я никогда не получал это завершение снова. это работало, план состоял в том, чтобы отметить третий диск, как отказавший, удалить его и вырастить массив назад к двум устройствам (или два устройства и недостающая запчасть.)

Вы видите что-то не так с какой-либо этой процедурой сборки?

Я приношу извинения за длинное сообщение. Я хотел попытаться предоставить как можно больше информации, чтобы попытаться ожидать любые вопросы.

Любые предложения значительно ценятся. Я особенно обеспокоен тем, что заставляет систему паниковать.

---

Все ниже здесь было добавлено суббота, 15 ноября 2014

---

Во-первых, позвольте мне разъяснить очевидное недоразумение. @psusi записал:

Так как Вы не упоминали, что создали файловую систему на массиве RAID и смонтировали его после создания массива, и mdadm предупредил Вас, что/dev/sdc1 уже имеет ext2 файловую систему в нем, я предполагаю, что Вы подразумеваете, что у Вас уже есть файловая система в/dev/sdc1, и именно это повторно монтируется только для чтения.

Нет. Корневая файловая система находится на своем собственном твердотельном диске SATA-III (sda1), в то время как я пытаюсь создать зеркало md2 использование двух других дисков на 4 ТБ (sdc и sdd). Это - в то время как это зеркало синхронизирует это, что-то идет не так, как надо, вся системная паника, и это - корневая файловая система, не зеркало, которое повторно смонтировано только для чтения, делая всего неоператора ОС и требуя жесткой перезагрузки. На перезагрузку зеркала, по-видимому, предпринимают, чтобы быть восстановленным, но теперь обычно называют/dev/md127.

Да, я пытался создать зеркало с помощью двух дисков, которые были ранее разделены с таблицей разделов GPT и затем отформатированы с одной большой ext4 файловой системой. От всего я читал, это должно быть приемлемо.

[ПРИМЕЧАНИЕ: То, когда mdadm говорит "/dev/sdd1, кажется, содержит ext2fs файловую систему", он не распознает ext4fs - вероятно, из-за трудно кодированного сообщения об ошибке, которое правильно никогда не обновлялось. До типов раздела GParted не позволяет им быть отформатированными как тип fd непосредственно, но я действительно полагаю, что mdadm отмечает их как таковой, когда он собирает их в массив.]

Основанный на комментариях ниже, это - то, что я попробовал:

1: Я запустил расширенный тест поверхности S.M.A.R.T. на всех четырех дисках на 4 ТБ (2 для зеркала, 2, поскольку будущее экономит). Каждый тест принял 8,5 часов и все диски, о которых сообщают без ошибки. Осуществление этих дисков индивидуально никогда не вызывало системную панику.

2: Используя GParted, я удалил ext4 разделы из sdc и sdd дисков.

3: Чтобы удостовериться, что исходные таблицы разделов GPT были устранены, я работал:

# sgdisk -Z /dev/sdc
# sgdisk -Z /dev/sdd

4: Я воссоздал массив с помощью двух бесформатных дисков.

# mdadm --create /dev/md2 --verbose --level=1 --metadata 1.2 --raid-devices=2 /dev/sdc /dev/sdd
mdadm: size set to 3906887360K
mdadm: array /dev/md2 started

5: Я начал контролировать синхронизацию с помощью "кошку/proc/mdstat" и видел, что он совершенствовался приятно.

После нескольких минут система, испуганная, как обычно, и корневая файловая система (sda1), была повторно смонтирована RO и потребовала жесткой перезагрузки. На перезагрузку массив был переименован в/dev/md127 и в этом случае, это находится в "resync=PENDING", указывают, и автоматически не пытается синхронизировать. Намерение состояло в том, чтобы создать таблицу разделов GPT и ext4 раздел на зеркале, после того как это закончило синхронизировать. (Я знаю, что, возможно, вероятно, шел вперед и сделал это во время синхронизации, но я пытаюсь изолировать шаги в этом процессе для наблюдения, где проблема заключается.)

Вот некоторая новая информация, которую я нашел дублированным в файлах системного журнала и kern.log. Эти сообщения были зарегистрированы только до операции перемонтирования-ro.

Nov 15 14:31:15 dymaxion kernel: [58171.002154] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 15 14:31:15 dymaxion kernel: [58171.002163] ata8.00: failed command: IDENTIFY DEVICE
Nov 15 14:31:15 dymaxion kernel: [58171.002167] ata8.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 16 pio 512 in
Nov 15 14:31:15 dymaxion kernel: [58171.002167]          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 15 14:31:15 dymaxion kernel: [58171.002169] ata8.00: status: { DRDY }
Nov 15 14:31:15 dymaxion kernel: [58171.002175] ata8: hard resetting link
Nov 15 14:31:15 dymaxion kernel: [58171.329795] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Nov 15 14:31:15 dymaxion kernel: [58171.330336] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.334346] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.339116] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.343149] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.347557] ata8.00: configured for UDMA/133
Nov 15 14:31:15 dymaxion kernel: [58171.347625] ata8: EH complete

Это, кажется, указывает на своего рода ошибку SATA, хотя, в данный момент я не могу интерпретировать ее.

Так, это дает какие-либо дополнительные представления относительно того, что может быть неправильным? Я действительно ценю справку к настоящему времени. Это получило меня думающий в паре новых направлений. Я надеюсь, что кто-то может обеспечить дальнейшее понимание или предложения.Спасибо.

---

Все ниже здесь было добавлено суббота, 20 декабря 2014

---

Как заключительная запись в этой саге, я предоставляю следующую информацию в надеждах, что она поможет другим в будущем.

Мне действительно удавалось выйти на связь с американской поддержкой ASUS относительно этой проблемы. Я получил заменяющую материнскую плату Z9PE-D8 WS, которую я установил и настроил. Когда я запустил свои тесты RAID, я закончил тем, что наблюдал точно те же результаты как с исходной материнской платой. С корневым диском файловой системы, подключенным к контроллеру Чуда:

• Если дополнительный RAID, 1 диск был на контроллере Чуда, любая попытка выполнить значительный mdadm (8) операция на массиве, генерировал исключение ядра и ошибки, отмеченные выше, и вся ОС запаникует.

• Если бы диски RAID отъехались контроллера Чуда, то mdadm (8) операции мог быть выполнен без проблемы и системы, управляемой без проблемы.

Так как я намеревался зеркально отразить корневой раздел, я стремился видеть то, что произошло бы, если бы корневая файловая система была удалена из контроллера Чуда, и RAID попятился на него. К сожалению, я не мог найти способ когда-либо загрузить ОС, если бы корневая файловая система была перемещена во встроенный чипсет Intel C602. Это имело место с обеими материнскими платами.

[ПРИМЕЧАНИЕ: Если у кого-либо будет подсказка, почему это не могло быть сделано, я буду ценить слушание причины. Например, GRUB2 хранит некоторую особую информацию во время установки, которое является определенным для контроллера?]

Поэтому я стиснул зубы и решил полностью переустановить последнюю Серверную версию 14.10 Ubuntu и зеркально отразить корневую файловую систему как часть процесса установки. Я переместил SSD в пару портов SATA-III, которыми управляет контроллер Intel, и выполнил новую установку. Все хорошо работало.

Теперь, с рабочей системой с зеркальным корнем, я подключил два диска на 4 ТБ к контроллеру Чуда и попытался создать новый массив RAID 1. Массив скоро перестал работать. Таким образом мы можем окончательно прийти к заключению, что контроллер Чуда делает что-то, что является несовместимым с управлением программным обеспечением RAID.

Я переместил диски на 4 ТБ в порты SATA-II, которыми управляет Intel C602, и все работало и продолжает работать без помехи. Разработка ASUS изучает проблему, в то время как меня оставляют с машиной, где четыре из исходных шести портов SATA-III неприменимы.

Урок - то, что любой рассматривающий машину Linux, которая использует контроллер PCIe 9230 Чуда, должен быть обеспокоен совместимостью RAID.

Я надеюсь, что эта информация полезна. Если кто-либо еще обнаруживает подобные проблемы с контроллером Чуда и может пролить дальнейший свет на предмет, свяжитесь со мной.Спасибо. ~