如何使不活动的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该设备再次处于活动状态。（我不确定当它处于非活动状态时是否会相同。）

解决方法：正如吉米·赫德曼（Jimmy Hedman）所建议的，我的输出是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不活动的设备等。

conf文件应如下所示-即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设备上添加一个数组，并将其添加到文件末尾的上述注释之后（如果不存在此类注释）。您可以通过执行sudo mdadm -E --scan以下操作获得UUID ：

$ 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桌面10.04 LTS，据我所知，此行为不同于Ubuntu的服务器版本，但是在很久以前，我在服务器上创建了md设备，这可能是错误的。也可能是我只是错过了一些选择。

无论如何，在conf文件中添加数组似乎可以解决问题。我已经连续进行了上述袭击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

但是，阵列详细信息显示，它在5个设备中有4个可用：

[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

到那时，阵列已启动，并与5台设备中的4台一起运行，我能够添加替换设备并对其进行重建。我可以毫无问题地访问文件系统。

我在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

这是一个fakeraid0。我在/ 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，并且计算机正在尝试使用旧的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认为该阵列由于离线的旧阵列名称而已处于活动状态）。