☰

通过 mdadm 创建 RAID 1 最终会在同步后完全填满其中一个驱动器

tag-icon • tag-icon ubuntu raid software-raid mdadm raid1
通过 mdadm 创建 RAID 1 最终会在同步后完全填满其中一个驱动器

我有一台配备 2 个 1TB NVMe 驱动器的服务器，我希望它们在软件 RAID 1（mdadm）中作为系统驱动器工作。创建并等待阵列同步后，我发现阵列中的一个驱动器已完全填满。通过nvme list或检查df -h显示它们看起来完全未同步。首先，我从 Hetzner（拍卖）购买了一台新服务器，在自动安装 Ubuntu 20.04 LTS 并等待驱动器重新同步后，我注意到了这个问题，移除这个已满的驱动器并再次添加到 mdadm 没有帮助。已经通过重新安装到 22.04 进行了测试 - 同样的问题。然后在 Hetzner Rescue 系统中手动格式化和设置此阵列。驱动器同步后我总是以此结束（它们两个都只是有清晰的操作系统）我总是以以下方式结束nvme list：

    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     S3W6NX0Mxxxxxx       SAMSUNG MZVLB1T0HALR-00000               1          19.80  GB /   1.02  TB    512   B +  0 B   EXA7301Q
/dev/nvme1n1     S3W6NX0Mxxxxxx       SAMSUNG MZVLB1T0HALR-00000               1           1.02  TB /   1.02  TB    512   B +  0 B   EXA7301Q

lsblk：

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0   3.1G  1 loop
nvme0n1     259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0    32G  0 part
│ └─md0       9:0    0    32G  0 raid1
├─nvme0n1p2 259:2    0     1G  0 part
│ └─md1       9:1    0  1022M  0 raid1
└─nvme0n1p3 259:3    0 920.9G  0 part
  └─md2       9:2    0 920.7G  0 raid1
nvme1n1     259:4    0 953.9G  0 disk
├─nvme1n1p1 259:8    0    32G  0 part
│ └─md0       9:0    0    32G  0 raid1
├─nvme1n1p2 259:9    0     1G  0 part
│ └─md1       9:1    0  1022M  0 raid1
└─nvme1n1p3 259:10   0 920.9G  0 part
  └─md2       9:2    0 920.7G  0 raid1

fdisk -l：

Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SAMSUNG MZVLB1T0HALR-00000
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x95d349e3

Device         Boot    Start        End    Sectors   Size Id Type
/dev/nvme0n1p1          2048   67110911   67108864    32G fd Linux raid autodetect
/dev/nvme0n1p2      67110912   69208063    2097152     1G fd Linux raid autodetect
/dev/nvme0n1p3      69208064 2000407215 1931199152 920.9G fd Linux raid autodetect


Disk /dev/nvme1n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SAMSUNG MZVLB1T0HALR-00000
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x76027d35

Device         Boot    Start        End    Sectors   Size Id Type
/dev/nvme1n1p1          2048   67110911   67108864    32G fd Linux raid autodetect
/dev/nvme1n1p2      67110912   69208063    2097152     1G fd Linux raid autodetect
/dev/nvme1n1p3      69208064 2000407215 1931199152 920.9G fd Linux raid autodetect


Disk /dev/md0: 31.97 GiB, 34325135360 bytes, 67041280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 1022 MiB, 1071644672 bytes, 2093056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md2: 920.74 GiB, 988638674944 bytes, 1930934912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

mdadm -D /dev/md2（最大音量）

/dev/md2:
           Version : 1.2
     Creation Time : Fri Sep  2 01:43:35 2022
        Raid Level : raid1
        Array Size : 965467456 (920.74 GiB 988.64 GB)
     Used Dev Size : 965467456 (920.74 GiB 988.64 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri Sep  2 03:06:37 2022
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : rescue:2  (local to host rescue)
              UUID : 9140be20:6c29229f:d572b5ba:dee1f0a3
            Events : 895

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync   /dev/nvme0n1p3
       1     259       10        1      active sync   /dev/nvme1n1p3

和cat /proc/mdstat

Personalities : [raid1]
md2 : active raid1 nvme1n1p3[1] nvme0n1p3[0]
      965467456 blocks super 1.2 [2/2] [UU]
      bitmap: 0/8 pages [0KB], 65536KB chunk

md1 : active raid1 nvme1n1p2[1] nvme0n1p2[0]
      1046528 blocks super 1.2 [2/2] [UU]

md0 : active raid1 nvme1n1p1[1] nvme0n1p1[0]
      33520640 blocks super 1.2 [2/2] [UU]

unused devices: <none>

在我看来一切都很正常，有人知道为什么阵列重新同步后第二个驱动器会完全填满吗？只是要说一下，这不是我在 Hetzner 上的第一台服务器 - 其他类似配置的服务器在使用上没有区别。

答案1

“重新同步”过程意味着“确保驱动器上的数据一致”。请注意，MD RAID 是一个单独的块级设备，它对上面的内容一无所知。文件系统？不知道。LVM？可能。原始 Oracle ASM 表空间？也许。根本没有使用？这种情况会发生。组装后，MD RAID 将继续工作，并确保所有组件设备彼此一致。这就是它所能做的一切，也是它的设计目的。

因此，为了确保两个 RAID1 设备一致，它只是将一个设备逐块复制到另一个设备。读取一个驱动器输出的任何数据并将其写入另一个驱动器。它不关心该块中存储了什么数据（以及该块是否由文件系统使用）；它只是指示一个设备的 M 到 N 块应该与另一个设备上的 M 到 N 块相同。这意味着，在重新同步期间至少会有一个驱动器被完全写入。

可以稍微缓解这种情况的方法是事后修剪驱动器。您可以向RAID 本身，如果启用了向下传递，它会将其转换为 NVMe 命令。要检查这一点，您可以执行lsblk --discard。要进行修剪，您可以例如创建一个跨越整个阵列的文件系统并将fstrim其。

相关内容