☰

md raid5 丢弃速度极慢

tag-icon • tag-icon linux raid ssd raid5 centos8
md raid5 丢弃速度极慢

大家好，md raid 专家

运行 Centos 8（包含所有最新更新，内核 4.18.0-240.1.1.el8_3.x86_64），其中我在 raid5 中有 3x2T Samsung SSD 860 QVO 2TB（用作某些 KVM VM 的基础），当我执行涉及丢弃的操作时，它不仅速度慢，而且远远超出了可用性。我确实创建了一个 1.5T LV，然后执行了“mkfs.ext4”，4 小时后，丢弃阶段告诉我“丢弃设备块：10489856/409148416”，起初我在想“4 小时 25%，这太糟糕了”，但后来我意识到它只有 2.5%，所以我们谈论的是一周！

我确实拆分了团队并对 3 个单独的驱动器执行了 blkdiscard，每个驱动器大约花费 18 秒。

硬件是带有智能阵列 P420i 控制器的 HP Proliant DL380p Gen8（没有特殊驱动程序，全部使用库存 Centos 驱动程序。）我将其配置为 HBA 模式，因此它应该只是一个直通（如果使用 hw raid，则根本不支持丢弃）。

在设备上执行丢弃操作后，我再次使用以下方法创建了突袭

mdadm --create /dev/md20 --level=5 --raid-devices=3 --chunk=64 /dev/sd{b,d,e}1

我把它放了一夜来同步。然后我创建了一个 vg 并测试了 lv 创建，花了 7 分钟才丢弃了 100M

root@terrok:~ # lvcreate -nDELME -L100M vgssd2  && date && time mkfs.ext4 /dev/vgssd2/DELME && date && time lvremove -f /dev/vgssd2/DELME;date
  Logical volume "DELME" created.
Mon Dec 21 12:47:42 EST 2020
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f7cf3bb6-2764-4eea-9381-c774312f463b
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


real    7m20.095s
user    0m0.004s
sys     0m0.195s
Mon Dec 21 12:55:02 EST 2020
  Logical volume "DELME" successfully removed

real    7m17.881s
user    0m0.018s
sys     0m0.120s
Mon Dec 21 13:02:20 EST 2020
root@terrok:~ #

作为比较，在同一系统上，我在 raid1 中也有两个 WDC WDS100T2B0A-00SM50（1T SSD），并且丢弃速度更快，10G 只需 4 秒。

然后我拿了两块三星固态硬盘，把它们组成一个 raid1，丢弃时全速运行。对其他两个驱动器组合重复上述操作，没有问题。对我来说，这表明 raid5 存在一些问题。目前，我在 raid1 中有两个固态硬盘，一个热备用，这至少可以正常工作，但当然比我预期的少了 2T 空间。

关于如何才能使其与 raid5 一起使用，有什么建议吗？

答案1

正如您的测试所表明的，RAID5 确实比简单的 RAID 1 阵列需要更多密集的操作。因为 RAID 1 实际上只是在两个磁盘之间进行同步而已。

另一方面，RAID 5 必须在三个磁盘之间进行所有这些计算和将它们进行奇偶校验。这需要做很多工作，至少与“简单”的 RAID 1 阵列相比。

另外，QVO 驱动器并不适合用于服务虚拟机等负载，因为这类负载通常驱动器的活动非常紧张。RAID 5 等奇偶校验阵列也不适合。您可能想根据上述情况以及 RAID5 本身的情况重新考虑您的部署策略。

答案2

我也刚刚解决了这个问题。我深入研究了 raid5 的驱动程序，发现 raid5 将传入的丢弃请求分解为底层设备上的 4k 丢弃请求。此外，它已经坏了很长一段时间，因此它实际上忽略了 devices_handle_discard_safely。结果，所有 4k 丢弃都与底层设备同步完成，这使得它总体上变得更加缓慢。旁注：我很快就会把它带到 LKML，所以你可以在那里继续关注。我不熟悉现有内核的任何解决方法。

相关内容