主页 / ubuntu / 问题 / 548405
Accepted
Jeffery Small
Asked: 2014-11-12 10:40:03 +0800 CST

导致系统崩溃的严重 RAID 问题

  • 772

系统：双至强 E5-2630 CPU，32GB 内存，主磁盘是 SATA-III 512GB Crucial SSD 操作系统：Xubuntu 14.04.1

我在这个新系统上遇到了 RAID 的严重问题，希望你们中的一些人能提供一些见解。目前，带有根文件系统的主 SSD 没有镜像，尽管我计划在未来将它镜像到第二个相同的 SSD。我正在尝试在辅助 HDD 组上设置 RAID，并且在解决此问题之前不愿升级主 SSD 组。

我在这个系统中有一对 SATA-III Seagate ST4000DM0004TB Baracuda 4TB 驱动器，它们的格式与单个大型 ext4 GPT 分区相同。我一直在尝试在这些磁盘上创建一个有用的 RAID 1 镜像，然后将其安装在 /x 上。有一次我有一些看起来很稳定的东西运行了几周，直到我试图修改阵列，此时它失败了。每次镜像失败时，系统显然会崩溃，SSD 上的根文件系统会根据 /etc/fstab 中的设置重新挂载为只读 (errors=remount-ro)。当然，系统现在没用了，需要硬重置。系统重新启动，但镜像现在已完全损坏，通常必须销毁并重建。我已经运行了硬件诊断程序，没有发现任何问题。关于任何日志文件（dmesg、kern.log、syslog）中的错误提示为零。以下是一些细节：

我按如下方式创建数组：

# 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% 之间的任何地方），系统出现恐慌并且 root 被重新挂载到 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

我曾尝试在一个安静的系统上构建阵列，除了几个终端窗口外，没有运行任何桌面进程。我已经运行了 checkbox-gui 硬件测试套件，一切正常。我尝试拔掉所有其他 SATA 磁盘、USB 端口、读卡器、光盘等，然后运行构建，但仍然失败。

任何人都可以找出阵列失败的某些原因或建议一些方法来更好地确定正在发生的事情吗？

这里有一些关于我的努力的额外信息。

在过去的 10 年里，我一直在我的 Sun 服务器 (Solaris 10) 上做的是将第三个磁盘连接到阵列，允许它同步，将它与阵列分离，然后将它从现场移走以进行灾难恢复。这一直工作得很好，这就是我计划在这个 Ubuntu 系统上做的。

使用上述过程，我曾经设法用两个内部磁盘正确构建 /dev/md2。系统运行了几个星期都没有问题，所以我准备使用热插拔托架连接第三个磁盘。我用热插拔托架中的第三个磁盘重新启动。由于任意设备重新分配，新磁盘显示为 /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。最终我不得不摧毁它并重新开始。我再也没有这么接近过。如果这有效，计划是将第三个磁盘标记为发生故障，将其移除并将阵列增长回两个设备（或两个设备和一个丢失的备用设备。）

您是否发现此构建过程有任何问题？

我为长篇文章道歉。我想尝试提供尽可能多的信息，以尝试和预测任何问题。

非常感谢任何建议。我特别关心是什么导致系统崩溃。

以下所有内容均于 2014 年 11 月 15 日星期六添加

首先，让我澄清一个明显的误解。@psusi 写道：

由于您没有提到在 raid 阵列上创建文件系统并在创建阵列后挂载它，并且 mdadm 警告您 /dev/sdc1 中已经有一个 ext2 文件系统，我猜您的意思是您已经有一个文件系统/dev/sdc1，这就是以只读方式重新挂载的内容。

不。当我尝试使用另外两个 4TB 磁盘（sdc 和 sdd）构建 md2 镜像时，根文件系统位于其自己的固态 SATA-III 驱动器 (sda1) 上。正是在这个镜像同步的时候出了点问题，整个系统都崩溃了，是根文件系统，而不是镜像，被重新挂载为只读，导致整个操作系统无法运行，需要硬重置。重新启动后，显然试图重建镜像，但现在通常命名为 /dev/md127。

是的，我试图使用两个磁盘创建镜像，这两个磁盘之前使用 GPT 分区表进行分区，然后使用一个大型 ext4 文件系统进行格式化。从我读过的所有内容来看，这应该是可以接受的。

[注意：当 mdadm 说“/dev/sdd1 似乎包含一个 ext2fs 文件系统”时，它错误地识别了 ext4fs——可能是由于从未正确更新的硬编码错误消息。至于分区类型，GParted 不允许将它们直接格式化为 fd 类型，但我相信 mdadm 在将它们组装到数组中时会这样标记它们。]

根据下面的评论，这就是我尝试过的：

1：我对所有四个 4TB 驱动器（2 个用于镜像，2 个作为未来备用）运行了扩展的 SMART 表面测试。每次测试耗时超过 8.5 小时，所有磁盘都报告无误。单独执行这些磁盘从未导致系统崩溃。

2：使用 GParted，我从 sdc 和 sdd 磁盘中删除了 ext4 分区。

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：我开始使用“cat /proc/mdstat”监控同步并看到它进展顺利。

几分钟后，系统像往常一样崩溃，根文件系统 (sda1) 被重新挂载到 RO 并需要硬重置。重新启动后，阵列被重命名为 /dev/md127，在这种情况下，它处于“resync=PENDING”状态，不会自动尝试同步。目的是在完成同步后在镜像上创建 GPT 分区表和 ext4 分区。（我知道我本可以在同步期间继续执行此操作，但我正在尝试隔离此过程中的步骤以查看问题所在。）

这是我在 syslog 和 kern.log 文件中发现的一些重复信息。这些消息是在 remount-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 错误，但目前我无法解释它。

那么，这是否提供了关于可能出错的任何额外线索？我真的很感谢到目前为止的帮助。它让我思考了几个新的方向。我希望有人可以提供进一步的见解或建议。谢谢。

以下所有内容均于 2014 年 12 月 20 日星期六添加

作为这个传奇的最后一个条目，我提供以下信息，希望它能在未来帮助其他人。

我确实设法就此问题联系了美国华硕支持部门。我收到了我安装和配置的更换 Z9PE-D8 WS 主板。当我运行我的 RAID 测试时，我最终观察到与原始主板完全相同的结果。将根文件系统驱动器连接到 Marvel 控制器：

  • 如果额外的 RAID 1 磁盘位于 Marvel 控制器上，则任何在阵列上执行重要 mdadm(8) 操作的尝试都会产生上述内核异常和错误，并且整个操作系统都会崩溃。

  • 如果将 RAID 磁盘从 Marvel 控制器中移出，则可以毫无问题地执行 mdadm(8) 操作，并且系统可以毫无问题地运行。

因为我打算镜像根分区，所以我很想知道如果从 Marvel 控制器中删除根文件系统并将 RAID 移回它上面会发生什么。不幸的是，如果将根文件系统移至板载 Intel C602 芯片组，我将无法启动操作系统。两块主板都是这种情况。

[注意：如果有人知道为什么不能这样做，我将很高兴听到原因。例如，GRUB2 是否在安装时存储了一些特定于控制器的特定信息？]

因此，我硬着头皮决定完全重新安装最新的 Ubuntu Server 14.10 版，并在安装过程中镜像根文件系统。我将 SSD 移至由 Intel 控制器控制的一对 SATA-III 端口并执行全新安装。一切正常。

现在，有了一个带镜像根的运行系统，我将两个 4TB 驱动器连接到 Marvel 控制器并尝试构建一个新的 RAID 1 阵列。阵法很快失效。因此，我们可以得出结论，Marvel 控制器正在做一些与软件 RAID 管理不兼容的事情。

我将 4TB 驱动器移至由 Intel C602 控制的 SATA-II 端口，一切正常并且继续正常工作。华硕工程师正在调查这个问题，而我只剩下一台机器，原来的六个 SATA-III 端口中有四个无法使用。

教训是，任何考虑使用 Marvel PCIe 9230 控制器的 Linux 机器的人都应该关注 RAID 兼容性。

我希望这些信息有用。如果其他人发现 Marvel 控制器存在类似问题并且可以进一步阐明该主题，请与我联系。谢谢。~

partitioning

3 个回答

  1. 我看到的最大问题是这个

    mdadm: /dev/sdd1 appears to contain an ext2fs file system

    此外，这些分区应标记为RAID 成员（类型 fd），而不是 Linux 文件系统。

    这意味着 extfs 工具可以锁定超级块，例如 fsck，并把你的世界搞得一团糟。我强烈建议您在使用 dd 将它们添加到阵列之前完全擦除驱动器。

    dd if=/dev/zero of=/dev/bye-bye-entire-sd-device

    确保你正在用你的文件系统格式化 MD 设备，而不是成员。

    如果一切正常并且您仍然看到随机损坏，那么您可能有一些边缘内存每隔一段时间就会写回垃圾并破坏您的磁盘。

    进一步参考：https ://raid.wiki.kernel.org/index.php/RAID_setup

    • 0

  2. 由于您没有提到在 raid 阵列上创建文件系统并在创建阵列后挂载它，并mdadm警告您 /dev/sdc1 中已经有一个 ext2 文件系统，我猜您的意思是您已经在 /dev/sdc1 中有一个文件系统dev/sdc1，这就是以只读方式重新挂载的内容。这是因为从磁盘或分区创建 raid 阵列通常是破坏性操作，因此为什么要mdadm警告您。通过将 raid 元数据写入分区，您已经损坏了那里现有的文件系统。

    此时，如果您想恢复 /dev/sdc1 中的现有数据，您需要尝试撤消您造成的损坏。首先卸载旧文件系统，然后清除您创建的 raid 超级块，然后 fsck 旧文件系统并希望它可以修复：

    umount /dev/sdc1
mdadm --zero-superblocks /dev/sdc1 /dev/sdd1
e2fsck -fy /dev/sdc1

    To upgrade an existing filesystem to a raid1, you first need to create the raid array using only the new disk, then manually copy all of your files from the old FS to the new one:

    mdadm --create --level 1 -n 2 /dev/sdd1 missing
mkfs.ext4 /dev/md0
mkdir /mnt/new
mkdir /mnt/old
mount /dev/md0 /mnt/new
mount /dev/sdc1 /mnt/old
cp -ax /mnt/old/* /mnt/new/
umount /mnt/old
umount /mnt/new
rmdir /mnt/old
rmdir /mnt/new

    Now edit your /etc/fstab to mount the new volume in /dev/md0 instead of the old one in /dev/sdc1, and finally you can hand /dev/sdc1 over to md to mirror everything in /dev/sdd1 onto:

    mdadm /dev/md0 --add /dev/sdc1

    You can use blkid to look up the UUID of the new filesystem in the raid array and use that to replace the old UUID in /etc/fstab. Also all of these commands must be run as root, so you will want to sudo -s first to become root.

    Finally, FYI, you might want to use raid10 instead of raid1. With the offset layout ( -p o2 to mdadm ) and a largish chunk size size ( -c 1024 to 4096 ), you can get the redundancy of raid1 plus the sequential read throughput of raid0.

    • 0
  3. Best Answer

    Looking for love in all the wrong places ....

    Thank you psusi and ppetraki for your helpful replies. You each gave me additional insights into how RAID functions under Linux.

    It turns out that there was nothing wrong with the disks or the mdadm commands that I was using to create and manipulate the RAID arrays. Once I discovered the ata8 kernel messages, I searched the internet using them as a key and found others reporting similar messages which were associated with a Marvel SATA controller. I have an ASUS Z9PE-D8 WS motherboard with an on board Marvel PCIe 9230 controller driving four SATA-III ports which were being used for these disks. I unplugged the drives from these ports, connected them to other SATA ports on the board that were being driven by an Intel C602 chipset and rebooted. At this point I was able to build multiple arrays, reconfigure them, etc. without any problem!

    The single SSD with the root filesystem is still attached to the Marvel controller and has exhibited no problem running. However, I now have no plans to attempt to mirror this drive until it is also removed from the Marvel controller.

    I am attempting to get some information out of ASUS regarding this issue. I do not know it it could indicate a hardware or a BIOS problem. So far, ASUS technical support has been slow to respond to my requests. I'm not impressed with their service.

    If anyone had additional information related to the Marvel controller problems, I would certainly appreciate hearing about it.

    So, I am back in business for the time being, four SATA-III ports shy of a properly working system. Thanks again for the assistance.

    • 0

相关问题