如何使用 mdadm 调整 RAID1 阵列的大小？

Question 1

只需使用

mdadm --grow --size max /dev/md2

然后你就可以使用

resize2fs /dev/md2

让文件系统与 raid 大小匹配。所有这些都是在线完成的，甚至无需卸载 md2。

Answer

只需使用

mdadm --grow --size max /dev/md2

然后你就可以使用

resize2fs /dev/md2

让文件系统与 raid 大小匹配。所有这些都是在线完成的，甚至无需卸载 md2。

Question 2

从看/proc/分区，很明显，Linux 认为sda3和sdb3比它们小。

计算分区大小总和

8       17      96358 sdb1
8       18    3903795 sdb2
8       19  152248005 sdb3

您将得到一个比磁盘大小小得多的数字。

8       16  488386584 sdb

152248005 个 1024 字节的块与大小一致mdadm --grow，并且resize2fs正在报告MD2 的。

您是否最初创建了这些较小大小的分区，然后后来重新创建它们以利用其余磁盘？如果是这样，重新启动应该允许内核重新读取分区表。之后，扩大 RAID 设备并调整文件系统大小应该可以正常工作。

Answer

从看/proc/分区，很明显，Linux 认为sda3和sdb3比它们小。

计算分区大小总和

8       17      96358 sdb1
8       18    3903795 sdb2
8       19  152248005 sdb3

您将得到一个比磁盘大小小得多的数字。

8       16  488386584 sdb

152248005 个 1024 字节的块与大小一致mdadm --grow，并且resize2fs正在报告MD2 的。

您是否最初创建了这些较小大小的分区，然后后来重新创建它们以利用其余磁盘？如果是这样，重新启动应该允许内核重新读取分区表。之后，扩大 RAID 设备并调整文件系统大小应该可以正常工作。

Question 3

我经常使用 mdadm，认为它是最危险的 Linux 实用程序之一。但是，如果您采取正确的安全预防措施，则可以避免大多数潜在的数据丢失情况备份所有数据!!! 我以前曾两次被 mdadm 攻击过，丢失了超过 700GB 的数据，而且只有极少数数据能够恢复，我已警告过你。

您很有可能需要再次创建 RAID 阵列，因为 mdadm 不会预期或补偿驱动器突然增大的大小。它将使用 raid 超级块中规定的大小，而不是驱动器本身。如果驱动器已经同步，您不应该遇到太多问题。

请记住，如果您想启动它，请使用超级块版本 0.9。

编辑

我会这样做，未经测试！

创建一个缺少驱动器的 RAID1，这样我们就可以快速测试数据是否保留，同时仍有另一个驱动器包含数据的副本，您的旧元数据是 0.90，因此我们将在此处保留相同的版本。

mdadm --create /dev/md2 --level=mirror --metadata=0.90 --raid-devices=2 missing /dev/sdb3

安装以测试一切是否正常

mkdir /mnt/test
mount /dev/md2 /mnt/test

检查你的数据

   ls -l /mnt/test

如果一切正常则卸载驱动器并调整大小。

unmount /mnt/md2
resize2fs /dev/md2

一旦一切正常，您就可以将另一个驱动器添加到阵列中。

mdadm --add /dev/md2 /dev/sdb3

并等待驱动器重新同步

猫/proc/mdstat

Answer

我经常使用 mdadm，认为它是最危险的 Linux 实用程序之一。但是，如果您采取正确的安全预防措施，则可以避免大多数潜在的数据丢失情况备份所有数据!!! 我以前曾两次被 mdadm 攻击过，丢失了超过 700GB 的数据，而且只有极少数数据能够恢复，我已警告过你。

您很有可能需要再次创建 RAID 阵列，因为 mdadm 不会预期或补偿驱动器突然增大的大小。它将使用 raid 超级块中规定的大小，而不是驱动器本身。如果驱动器已经同步，您不应该遇到太多问题。

请记住，如果您想启动它，请使用超级块版本 0.9。

编辑

我会这样做，未经测试！

创建一个缺少驱动器的 RAID1，这样我们就可以快速测试数据是否保留，同时仍有另一个驱动器包含数据的副本，您的旧元数据是 0.90，因此我们将在此处保留相同的版本。

mdadm --create /dev/md2 --level=mirror --metadata=0.90 --raid-devices=2 missing /dev/sdb3

安装以测试一切是否正常

mkdir /mnt/test
mount /dev/md2 /mnt/test

检查你的数据

   ls -l /mnt/test

如果一切正常则卸载驱动器并调整大小。

unmount /mnt/md2
resize2fs /dev/md2

一旦一切正常，您就可以将另一个驱动器添加到阵列中。

mdadm --add /dev/md2 /dev/sdb3

并等待驱动器重新同步

猫/proc/mdstat

Question 4

让我添加自己的日志，以作记录。我发现自己处于这样一种情况：多年来，在更换了古老的 MD 镜像中的两个驱动器后，我最终拥有的两个驱动器都比镜像原来的大小要大 :-) 我已经有了更大的物理驱动器，但 Linux RAID 分区仍然是原始的（= 较小）大小。而且，MD 镜像上的空间快用完了。幸运的是，每个驱动器只有一个 0xFD 分区，这使得扩展相对简单。

以下是我的“内部剪贴簿条目”的副本：

首先，我们来大致了解一下初始情况：

df
cat /proc/partitions
cat /proc/mdstat
cat /etc/mdadm/mdadm.conf

分区表是否相同？

sfdisk -d /dev/sdh
sfdisk -d /dev/sdi

为了以防万一，我们应该“停留”在安全的地方：

cd ~

您可能希望停止任何依赖于挂载点的服务。例如，如果该卷由 Samba 提供服务：

systemctl stop nmbd
systemctl stop smbd

如果您选择在线调整 FS 大小（这应该是更快的选项），显然甚至不需要卸载：

umount /array/mountpoint

现在，无论您是选择在线还是离线调整 FS 的大小，我都已经证实，为了调整 MD 设备的大小，您实际上必须不是停下来！

#mdadm --stop /dev/md3

您最好备份分区表 - 以防万一。显然，这不能替代完整备份所有数据，但如果由于某种原因您在修改分区表时犯了错误，它可以为您提供一条退路。

如果两个驱动器相同，则只需选择一个驱动器。

sfdisk -d /dev/sdh > sdh.bak

您的第一个也是唯一的分区可能从第 63 扇区开始。或者在现代大约是 2048。请注意以下命令中的数字 63。无论它是什么，只要保留它即可。

标记为 0xFD（= Linux RAID Autodetect）的分区正在被活动 MD 阵列使用。这是故意的，您只需强制 fdisk 进行更改即可。我使用的是“可编写脚本的”sfdisk，但如果这让您感到不安，您可能只需使用交互式版本：

echo -en "unit: sectors\n63,,fd,\n" | sfdisk --force /dev/sdh
echo -en "unit: sectors\n63,,fd,\n" | sfdisk --force /dev/sdi

请注意，在指定起始扇区（第二条磁道的起始位置）后，我们未指定分区大小 - 这表明 sfdisk 将使用所有可用空间。“fd”是分区标签（Linux RAID 自动检测）。尾随的逗号表示另一个字段保留为默认值 - 此处放置的星号表示活动=可引导分区。是\n换行符的转义序列。因为 sfdisk 的输入实际上是一个多行文件。请参阅 sfdisk -d 的输出。请注意，我之前使用此事实备份分区表，并通过简单的重定向将备份存储在文件中。该备份文件可以简单地通过管道传输到另一个 sfisk 的标准输入中，以重新创建该分区表。您还可以编辑文件以更改分区布局，然后再次将其通过管道传输到 sfdisk 中以实现更改...

在 fdisk 的输出跟踪中，您应该看到 fdisk 增加了分区大小，并报告有将新的分区表写入磁盘（因为我们强制这样做），但仍然没有告诉内核从磁盘重新读取分区表。也就是说，内核没有重新解释/更新其分区大小的概念，另请参阅：

cat /proc/partitions

然而，为了后续操作 mdadm --grow --size max成功，我们需要执行 parttable 重新读取操作。无需停止 MD 阵列！有几种工具可以为我们调用所需的 ioctl()，例如：

partprobe /dev/sdh
partprobe /dev/sdi

使用以下方法可能可以达到相同的效果：

blockdev --rereadpt /dev/sdh
blockdev --rereadpt /dev/sdi

重新检查结果：

cat /proc/partitions

最后，调整 MD 设备的大小：

mdadm --grow --size max /dev/md3

您最好等待数组完成同步增长的空间：

watch -n 5 cat /proc/mdstat

重新同步完成后，您可能需要检查阵列是否可以停止并重新启动：

mdadm --stop /dev/md3
mdadm --assemble scan --uuid=<check out the mdadm.conf>

或者

mdadm --assemble /dev/md3 /dev/sdh1 /dev/sdi1

这一步 = 数组停止/启动不是必需的 - 但如果成功，您就知道您可能（可能？）还没有丢失数据:-)

下面的示例针对 EXT2/3/4 FS 进行定制。

您可以尝试立即安装 MD 卷，然后在线执行 FS 大小调整。或者，您可以保持 MD 卷未安装，然后离线调整 FS 大小。resize2fs 根据条件的不同而采取的各种行为已之前曾在这里讨论过。

如果您尝试离线运行 resize2fs，即未安装 MD 卷时，它可能会要求您e2fsck -f先运行。

e2fsck -f -v /dev/md3

这需要很长时间！“-v”应该会给你更多关于进度的线索。并且，在 MD 同步完成之前不要运行 fsck！如果你这样做，它们会争夺 IOps，并且可能比按顺序执行花费更长的时间！

最后：

resize2fs -p /dev/md3

“-p”选项打开进度指示器。然后，是时候挂载

mount /array/mountpoint

并检查可用空间：

df

并开始您的服务...

实际上，您可以在挂载 FS 时调整大小 - 但旧版本的 ext3 不支持此功能。也就是说，此在线调整大小操作在后台运行。离线调整大小操作在前台运行，可能需要几十分钟（扩展。缩小可能需要几个小时）。这时 -p 参数（进度指示器）就派上用场了 :-)

在执行所有这些 resync / fsck / resize2fs 时，您可能会喜欢 IOps 监视器。我最喜欢的是 sysstat 包中的 iostat。例如，要每 2 秒自动刷新视图，请使用：

iostat 2

您可以在另一个终端窗口中继续运行此程序，除了您发出黑色诅咒的那个窗口之外。我在文件系统级别发现了另一个有用的“自动刷新监视器”，调用方式如下：

watch -n 10 df

我在将文件从一个磁盘复制到另一个磁盘时会用到它，例如将卷移到另一个文件系统时。如果您的情况如此，还请留意noatimemount 选项。

Answer