☰

/dev/md 设备在 Linux RAID1 阵列中消失

tag-icon • tag-icon linux software-raid xfs
/dev/md 设备在 Linux RAID1 阵列中消失

我继承了一台 NAS 服务器，该服务器设置了 5 个 RAID1 软阵列，这些阵列组合成一个 XFS 卷组。

无论是谁构建了第 5 个 md 设备，它都是在没有 Linux Auto RAID 分区的情况下创建的（看起来他们使用原始磁盘（即 /dev/sdj /dev/sdk）执行了 mdadm --create）。到目前为止它一直运行良好，但今天整个 /dev/md5 阵列消失了。

The /dev/sdj drive appears to be in the process of failing.   
Buffer I/O error on /dev/sdj logical block 0
Buffer I/O error on /dev/sdj logical block 1
Buffer I/O error on /dev/sdj logical block 2
Buffer I/O error on /dev/sdj logical block 3

通常情况下，我会认为 RAID 会使设备失效，但会使用第二个驱动器保持阵列正常运行。但是，当我 cat /proc/mdstat 时，我的 md5 设备不见了。我怀疑这是因为这两个驱动器没有自动 RAID 分区，但我不确定。

我尝试使用重新创建 md5 数组

mdadm --create /dev/md5 --level=1 --raid-devices=2 /dev/sdj /dev/sdk

但它说 sdj 已经是 RAID 设备的一部分

奇怪的是，XFS 卷组似乎仍能正常工作 - 据我所知，没有数据丢失，并且 df 仍显示所有可用空间。可能是 XFS 仍能看到 /dev/sdk 驱动器并能成功写入？sdj 和 sdk 都显示 fdisk -l。

我的问题是：

  1. 我可以安全地更换 /dev/sdj 驱动器而不弄乱（正在工作但易损坏的）XFS 卷吗？
  2. 如果 mdstat 说 md5 阵列不存在，但是 mdadm 说它存在，我该如何恢复/重建 md5 阵列？
  3. 如果我去将 Linux Auto RAID 分区添加到此阵列中剩余的良好驱动器，这会损坏其上已有的数据吗？
  4. 如何使用 XFS 验证数据完整性？（以确保确实没有数据丢失）

pvscan 的输出：

pvscan
  /dev/sdj: read failed after 0 of 4096 at 0: Input/output error
  /dev/sdj: read failed after 0 of 4096 at 2000398843904: Input/output error
  PV /dev/sdd2   VG VolGroup00   lvm2 [74.41 GB / 0    free]
  PV /dev/md2    VG dedvol       lvm2 [931.51 GB / 0    free]
  PV /dev/md3    VG dedvol       lvm2 [931.51 GB / 0    free]
  PV /dev/md0    VG dedvol       lvm2 [931.51 GB / 0    free]
  PV /dev/md4    VG dedvol       lvm2 [931.51 GB / 0    free]
  PV /dev/sdj    VG dedvol       lvm2 [1.82 TB / 63.05 GB free]
  Total: 6 [5.53 TB] / in use: 6 [5.53 TB] / in no VG: 0 [0   ]

磁盘 /dev/sdj：2000.3 GB，2000398934016 字节
255 个磁头、63 个扇区/磁道、243201 个磁柱
单位 = 16065 * 512 = 8225280 字节的柱面

磁盘 /dev/sdj 不包含有效的分区表

磁盘 /dev/sdk：2000.3 GB，2000398934016 字节
255 个磁头、63 个扇区/磁道、243201 个磁柱
单位 = 16065 * 512 = 8225280 字节的柱面

磁盘 /dev/sdk 不包含有效的分区表

mdadm --misc -Q /dev/sdj
/dev/sdj：不是 md 阵列
/dev/sdj：未找到 md 超级块，不是 md 组件。

mdadm --misc -Q /dev/sdk
/dev/sdk：不是 md 数组
/dev/sdk：2 设备中的设备 0 未检测到 raid1 /dev/md5。使用 mdadm --examine 了解更多详细信息。

mdadm——检查/dev/sdk
/dev/sdk：
          魔法：a92b4efc
        版本：0.90.00
           UUID：25ead1e4：9ab7f998：73875d59：48b17be5
  创建时间：2010 年 11 月 26 日星期五 21:10:49
     突袭级别：raid1
  已使用设备大小：1953514496 (1863.02 GiB 2000.40 GB)
     数组大小：1953514496（1863.02 GiB 2000.40 GB）
   突袭设备：2
  设备总数：2
首选辅修科目：5

    更新时间：2011年3月26日星期六07:43:52
          状态：干净
 活跃设备：2
工作装置：2
 故障设备：0
  备用设备：0
       校验和：35a405cb-正确
         活动：5720270


      编号 主要 次要 RaidDevice 状态
这 0 8 144 0 活动同步 /dev/sdj

   0 0 8 144 0 活动同步 /dev/sdj
   1 1 8 160 1 活动同步 /dev/sdk

答案1

因此，根据 上的超级块/dev/sdk，有一个/dev/md5并且 sdj 也在其中，但根据/dev/sdj，没有 raid 超级块。我担心的是 被/dev/sdj添加到 md5 阵列，然后/dev/sdj被添加到卷组（而不是/dev/md5），并且在某个时候 lvm 会覆盖将其标识为 RAID 设备成员的块。我担心这一点，因为我真的想不出 /dev/sdj 最终在 LVM 组中被明确命名并且不再具有 raid 超级块的任何其他方式。

最糟糕的噩梦场景：/dev/sdj 和 /dev/md5 都已添加到 LVM。您的 XFS 分区现在是否大于 LVM 中的 5.5 TB？如果是这种情况，您应该能够使用 md5 重新使用，mdadm --assemble但您需要确保它在没有 sdj 的情况下以降级模式启动，这样它就不会覆盖那里的数据。

假设你的 /dev/md5 从未在 LVM 中使用过：

pvscan（...今天之前你看过吗？）

如果你没有备份，现在是时候开始了。如果你有，现在是时候测试它们了（如果它们不起作用，说明你没有备份，请参阅步骤 1）。

没有简单的方法可以摆脱这种困境，而且我不知道如果此时重新启动会发生什么（您可以卸载文件系统吗？）。 如果我确信真正发生的事情是 sdj 已被添加为 raid 驱动器和作为 lvm 物理卷（由于 lvm 没有使用 raid 驱动程序写入 sdj，因此写入 sdj 的任何数据都不会在 sdk 上......也许可以通过比较 /dev/sdj 和 /dev/sdk 的各个块的十六进制转储来验证这一点，并且有比我更聪明的人知道在哪里可以找到“这是 XFS”而不是“这是随机的胡言乱语或空白驱动器”？），然后我会这样做：

首先尝试获取 sdk 上的 SMART 数据，看看它是否可信或是否即将消失。

如果 sdk 很好，那我要感谢我的幸运星，因为前任管理员浪费了 63GB 的/dev/sdj。

fdisk /dev/sdk

（在按回车键之前，请仔细检查所有内容）。让 fdisk 创建一个分区表和一个 md 分区（mdadm 手册页说使用 0xDA，但每个演练和我的经验都说 0xFD 是用于 raid 自动检测的），然后

mdadm --create /dev/md6 --level=1 --raid-devices=2 missing /dev/sdk1

（在按下回车键之前，请仔细检查所有内容）。这将使用我们在 sdk 上创建的分区创建一个名为 md6 的降级 raid1 阵列。接下来的步骤说明了浪费的空间为何如此重要：由于 md 超级块和分区表，我们损失了一些空间，因此我们的 /dev/md6 比 /dev/sdj 略小。我们将把 /dev/md6 添加到卷dedvol组，并指示 LVM 将 1.82TB 的逻辑卷从 /dev/sdj 移动到 /dev/md6。LVM 可以在执行此操作时处理处于活动状态的文件系统。

pvcreate /dev/md6
vgextend dedvol /dev/md6
pvmove -v /dev/sdj

（再检查一下……你明白了。我还会一次又一次pvscan地运行以确保一切正常）。这将开始将所有分配给的数据移动到的过程（具体来说，该命令将所有内容从 sdj 移出，而 md6 是它唯一可以去的地方）。几个小时后，这个过程要么完成，要么系统将锁定，尝试从 sdj 读取。如果系统崩溃，您可以重新启动并尝试在最后一个检查点重新启动，而无需使用设备名称，或者干脆放弃并从备份中重新安装。pvcreatevgextend/dev/sdj/dev/md6pvmove

如果成功，我们将从卷组中删除 /dev/sdj，然后将其作为物理卷删除：

vgreduce dedvol /dev/sdj
pvremove /dev/sdj

现在，我们来看看损坏检查部分。检查和修复 xfs 的工具是xfs_repair（fsck将在 xfs 文件系统上运行，但它什么也不做）。坏消息是？它每 TB 文件系统使用 GB 的 RAM，因此希望您拥有一台 64 位服务器，该服务器具有 64 位内核和 64 位 xfs_repair 二进制文件（可能名为 xfs_repair64），并且至少有 10GB 的 RAM+Swap（您应该能够使用 dedvol 中剩余的一些空白空间来创建交换卷，然后是mkswap该卷，然后是swapon该卷）。文件系统必须卸载在运行 xfs_repair 之前。此外，xfs_repair 可以检测并（尝试）修复文件系统本身的损坏，但它可能无法检测数据的损坏（例如，覆盖目录 inode 的一部分或覆盖文本文件中间的某些内容）。

最后，我们需要购买一个新的/dev/sdj，安装它，然后将其添加到降级的中/dev/md6，请记住，如果我们重新启动没有 sdj 的计算机，则 sdk 可能会移至 sdj 并且新驱动器将改为 sdk（可能不会，但最好确保）：

fdisk /dev/sdj

检查以确保它不是我们已经分区并设置的驱动器，然后在其上为 md 创建一个分区

mdadm /dev/md6 -a /dev/sdj1

（错误完全有可能是由于 raid 和 lvm 争夺 sdj 的内容而导致的，而不是驱动器实际发生故障（通常故障的驱动器会从驱动程序中产生大量乱码，而dmesg不仅仅是输入/输出错误）但我不确定我是否会冒这个险。）

相关内容