Як змусити знову неактивний пристрій RAID?

Після завантаження мій пристрій RAID1 ( /dev/md_d0*) іноді перебуває в якомусь смішному стані, і я не можу його встановити.

^{* Спочатку я створив, /dev/md0але він якось змінився /dev/md_d0.}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Пристрій RAID якось неактивне :

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

Питання в тому, як зробити пристрій знову активним (використовую mdmadm, я припускаю)?

(В іншому випадку після завантаження це нормально (активно), і я можу його встановити вручну без проблем. Але він все одно не зможе автоматично встановитись, хоча у мене це є /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Отже, питання про бонус: що мені робити, щоб пристрій RAID автоматично монтувався під /optчас завантаження? )

Це робоча станція Ubuntu 9.10. Основна інформація про моє налаштування RAID у цьому запитанні .

Редагувати : Моє /etc/mdadm/mdadm.confвиглядає так. Я ніколи не торкався цього файлу, принаймні від руки.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

В /proc/partitionsостанньому записі є , по md_d0крайней мере зараз, після перезавантаження, коли пристрій відбувається з активним знову. (Я не впевнений, чи було б те саме, коли він неактивний.)

Резолюція : як запропонував Джиммі Хедман , я взяв результат mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

і додав це в /etc/mdadm/mdadm.conf, що, здається, вирішило основну проблему. Після повторного /etc/fstabвикористання /dev/md0(замість /dev/md_d0) пристрій RAID також автоматично встановлюється!

Для вашого бонусного питання:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Я виявив, що мені потрібно додати масив вручну /etc/mdadm/mdadm.conf, щоб змусити Linux встановити його на перезавантаження. Інакше я отримую саме те, що у вас є, - md_d1неактивні пристрої тощо.

Конфі-файл повинен мати вигляд нижче - тобто один- ARRAYрядковий для кожного md-пристрою. У моєму випадку нових масивів у цьому файлі бракувало, але якщо у вас є їх у списку, це, ймовірно, не вирішує вашу проблему.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Додайте один масив на md-пристрій та додайте їх після коментаря, включеного вище, або якщо такого коментаря немає, в кінці файлу. Ви отримуєте UUID, виконавши sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

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

Я запускаю ubuntu desktop 10.04 LTS, і наскільки я пам’ятаю, така поведінка відрізняється від серверної версії Ubuntu, однак саме так давно я створив свої md-пристрої на сервері, можливо, я помиляюся. Можливо також, що я просто пропустив якийсь варіант.

У будь-якому разі, додавання масиву у конф-файл, здається, робить свою справу. Я впродовж багатьох років без проблем веду вищевказаний рейд 1 та рейд 5.

Попередження: Перш за все, дозвольте мені сказати, що наведене нижче (через використання "--force") для мене видається ризикованим, і якщо у вас є непоправні дані, я рекомендую зробити копії задіяних розділів, перш ніж почати спробувати будь-який з нижче. Однак це працювало для мене.

У мене була така ж проблема, коли масив виявився як неактивний, і я нічого не зробив, включаючи "mdadm --examine --scan> /etc/mdadm.conf", як запропонували інші тут, зовсім не допомагав.

У моєму випадку, коли він намагався запустити масив RAID-5 після заміни диска, він говорив, що він забруднений (через dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Викликаючи його виявитись неактивним у /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Я виявив, що всі пристрої мали однакові події на них, за винятком диска, який я замінив ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Однак деталі масиву показали, що в ньому було доступно 4 з 5 пристроїв:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(Вище сказано з пам'яті стовпця "Стан", я не можу знайти її у своєму буфері прокрутки).

Я зміг вирішити це, зупинивши масив, а потім повторно зібравши його:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

У цей момент масив був запущений, працюючи з 4 з 5 пристроїв, і я зміг додати пристрій для заміни, і він відбудовується. Я можу отримати доступ до файлової системи без проблем.

У мене виникли проблеми з Ubuntu 10.04, коли помилка в FStab не дозволила завантажувати сервер.

Я запустив цю команду, як згадувалося у вищезазначених рішеннях:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Це додасть результати з "mdadm --examine --scan" до "/etc/mdadm/mdadm.conf"

У моєму випадку це було:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Це підроблений номер 0. Моя команда в / etc / fstab для автоматичного монтажу:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Тут важливо, що у вас є "nobootwait" і "nofail". Nobootwait буде пропускати будь-які системні повідомлення, які заважають вам завантажуватися. У моєму випадку це було на віддаленому сервері, тому це було важливо.

Сподіваюся, що це допоможе деяким людям.

Ви можете активувати md-пристрій за допомогою

mdadm -A /dev/md_d0

Я думаю, що якийсь сценарій запуску запускається занадто рано, перш ніж був виявлений один з членів RAID або якась подібна проблема. Як швидке та брудне вирішення, ви повинні мати можливість додати цей рядок до /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Редагувати: мабуть, ваш /etc/mdadm/mdadm.conf все ще містить стару назву конфігурації. Відредагуйте цей файл і замініть виникнення md0 на md_d0.

У мене була подібна проблема ... мій сервер не монтував md2 після того, як я виростив пов'язані розділи пристроїв. Читаючи цю тему, я виявив, що на пристрої md2 RAID був новий UUID і машина намагалася використовувати старий.

Як було запропоновано ... використовуючи 'md2' вихід з

mdadm --examine --scan

Я відредагував /etc/mdadm/mdadm.confі замінив старий рядок UUID одним виводом зверху, і моя проблема пішла.

Коли ти робиш вигляд, що щось робиш з /dev/md[012346789}цим, йде до /dev/md{126,127...}. /dev/md0продовжує монтуватись /dev/md126або /dev/md127потрібно:

umount /dev/md127 або umount /dev/md126.

Це тимчасово, щоб ви могли виконувати команди та деякі програми, не зупиняючи вашу систему.

md_d0 : inactive sda4[0](S)виглядає неправильно для масиву RAID1. Здається, це дозволяє припустити, що в масиві немає активних пристроїв і одного запасного пристрою ^{_{(вказаного (S), ви б побачили (F) там для невдалого пристрою і нічого для OK / активного пристрою)}} - для масиву RAID1, який не є Якщо деградований запуск має бути принаймні двома ОК / активними пристроями ^{_{(а для деградованого масиву - щонайменше один ОК / активний пристрій),}} і ви не можете активувати масив RAID1 без жодних невідповідних пристроїв, що не спрацьовують (як запасні частини) не містять копії даних до тих пір, поки вони не стануть активними, коли інший диск вийде з ладу). Якщо я читаю це /proc/mdstatвихідне право, ви не зможете активувати масив у його поточному стані.

Чи є в машині фізичні накопичувачі, які не змогли закрутитися? Чи ls /dev/sd*перераховані всі диски та розділи, які ви зазвичай очікуєте побачити на цій машині?

Простий спосіб змусити запустити масив, припускаючи, що немає апаратних проблем, і у вас достатньо дисків / розділів для запуску масиву є наступний:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Можливо, з будь-якої причини масив є нормальним, але щось заважає йому запускатися або будуватися. У моєму випадку це було тому, що mdadm не знав оригінального імені масиву md127, і всі диски були відключені для цього масиву. Під час повторного підключення мені довелося збирати вручну (можливо, помилка, де mdadm вважав, що масив вже активний через стару назву офлайн-масиву).