☰

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 三星SSD 860 QVO 2TB（用作某些KVM 虛擬機的基礎），當我執行以下操作時涉及丟棄，它不僅慢，而且遠遠超出了可用範圍。我確實創建了一個1.5T LV，然後做了“mkfs.ext4”，4 小時後，丟棄階段告訴我“丟棄設備塊：10489856/409148416”，起初我在想“4 小時25%，這很糟糕” ，但後來我意識到只有 2.5%，所以我們討論了一周！

我確實分解了 raid，並對 3 個單獨的驅動器執行了 blkdiscard，每個驅動器大約花了 18 秒。

硬體是HP Proliant DL380p Gen8，具有智能陣列P420i 控制器（沒有特殊驅動程序，全部使用庫存Centos 驅動程序。），我將其配置為HBA 模式，因此它應該只是一個直通（如果使用硬件，則根本不支援丟棄）襲擊）。

在設備上進行丟棄後，我再次創建了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 秒。

然後，我確實拿了兩個三星 SSD 並對其進行了 raid1，丟棄時全速。對其他兩種驅動器組合重複此操作，沒有出現問題。對我來說，這表明了 raid5 的一些問題。現在，我在 raid1 中有兩個 SSD，其中一個熱備用，這至少可以工作，但空間當然比我預期的少了 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，所以你可以繼續關注那裡。我不熟悉現有內核可用的任何解決方法。

相關內容