抽象的
我有一个功能正常的 Raid 5 阵列，我重新启动了盒子，然后 mdadm 无法重新组装其中一个部件。
看到这只是一部分，我认为重新同步很容易。但事实证明这不起作用，因为显然现在设备还不够大，无法加入阵列！？
初始 Raid 设置
可悲的是相当复杂。我有一个 Raid 5，它结合了两个 3 TB 磁盘和两个线性 raid（由 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。但恐怕这实际上并没有改变设备的尺寸。
由于我不明白到底出了什么问题，所以在仓促行事之前，我宁愿首先了解导致此问题的原因。
答案1
所以呃...我想...好吧...磁盘...缩小了？
默认情况下，元数据的区域mdadm保留可能会增长...我最近遇到过一些案例，mdadm无缘无故地浪费了高达 128MiB 的空间。您想要检查mdadm --examine /dev/device*该data offset条目。理想情况下，扇区数不应超过 2048 个。
如果这确实是问题所在，您可以mdadm --create与该--data-offset=参数一起使用，以mdadm减少元数据浪费的空间。
如果这还不够，您必须尝试使用旧0.90元数据（这可能是最节省空间的，因为它不使用此类偏移量），或者稍微缩小 RAID 的另一侧（记住缩小首先是 LV/文件系统）。