妈妈；以前工作过；“失败”后，由于磁盘大小无法加入阵列

Question

抽象的

我有一个功能强大的 Raid 5 阵列，我重新启动了盒子，然后 mdadm 无法重新组装其中的一部分。

看到它只是一部分，我认为重新同步很容易。但结果证明这是行不通的，因为显然现在设备不够大，无法加入阵列！？

初始突袭设置

可悲的是相当复杂。我有一个 Raid 5，它结合了两个 3 TB 磁盘和两个线性突袭（由 1tb+2tb 组成）。我没有对磁盘进行分区，即raid跨越物理磁盘。事后看来，这可能是导致最初失败的原因。

在决定性的重启之后

mdadm 将拒绝组装线性阵列之一，声称不存在超级块（使用 mdadm --examine 对两者进行检查均未返回任何内容）。更奇怪的是，显然他们身上还有一些可分区的遗骸。

在这一点上，我认为最快的解决方案是重新创建线性阵列，将其添加到更大的 raid5 阵列，然后重新同步。因此我选择只删除那些分区表条目，即：将它们分区到可用空间。然后我创建了一个跨越两个磁盘的线性阵列。

# mdadm --create /dev/md2 --level=linear --raid-devices=2 /dev/sda /dev/sdc

但是，当尝试将它们添加回数组时，我得到

# mdadm --add /dev/md0 /dev/md2        
mdadm: /dev/md2 not large enough to join array

所以我正确地猜测磁盘缩小了？

计数块

我想是时候进行一些块计数了！

线性阵列的两个组成部分：

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   1000204886016   /dev/sda
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   2000398934016   /dev/sdc

如果 mdadm 的线性模式没有开销，则两个大小的总和将大于 3tb 驱动器之一 (3000592982016)。但事实并非如此：

/proc/mdstat 报告线性数组的大小为 2930015024，比所需的少 120016

# mdadm --detail /dev/md0 | grep Dev\ Size
Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)

但这……太可疑了！在重新启动之前（尽管更早的化身）这个线性阵列是更大阵列的一部分！

我相信的事情发生了

重新启动后，mdadm 识别出阵列的一部分丢失。由于它是最小的成员，因此阵列设备大小会自动增长以填充下一个最小的设备。

但这听起来不像呃，明智的行为，是吗？

另一种选择是，出于某种原因，我不再创建最大尺寸的线性突袭，但是……这也有点荒谬。

我一直在思考要做什么

收缩退化的数组以排除“损坏的”线性数组，然后再次尝试 --add 和 --grow。但恐怕实际上并不会改变设备大小。

由于我不明白到底出了什么问题，我宁愿先了解是什么导致了这个问题，然后再草率地做任何事情。

Answer 1

所以呃...我想...好吧...磁盘...缩小了？

默认情况下，元数据的区域mdadm保留可能会增长...我最近遇到过一些案例，mdadm无缘无故地浪费了高达 128MiB 的空间。您想要检查mdadm --examine /dev/device*该data offset条目。理想情况下，扇区数不应超过 2048 个。

如果这确实是问题所在，您可以mdadm --create与该--data-offset=参数一起使用，以减少mdadm元数据浪费的空间。

如果这还不够，您必须尝试使用​​旧元0.90数据（这可能是最节省空间的，因为它不使用此类偏移量），或者稍微缩小 RAID 的另一侧（记住缩小首先是 LV/文件系统）。