bcache 和/或 dm-cache 是否被認為在 2016 年生產穩定?
我想在 Debian Jessie 生產伺服器上使用 linux SSD 記憶體(dm-cache 或 bcache)。(核心 3.16)
我的問題: dm-cache 和 bcache 模組在 linux 3.16 中是否可靠?我需要將核心升級到更新的版本嗎?
我還發現了這個關於 bcache 的令人擔憂的消息:https ://lkml.org/lkml/2015/12/22/154
請注意,我完全理解記憶體模式選擇(回寫/直寫)在可靠性和數據失去方面的含義,我的問題更多是關於這些模組中的軟體錯誤
2018 年 2 月在持續集成伺服器上使用 bcache 一年多後跟進(jenkins 實例執行大量密集型作業!)
伺服器的配置(本質上是儲存堆棧)
硬體:
- 2 x 480GB SSD(三星 SM863 企業級 MLC)
- 2 個 4TB 硬碟(希捷 Constellation ES.3 SATA)
- 戴爾 R730 - 雙 Xeon E52670 - 128GB RAM
- 沒有硬體 RAID,沒有電池/快閃記憶體支持的硬體寫入記憶體,這就是 bcache 的回寫功能變得有趣的地方**。**
軟體:
2016 年 9 月配置,從未重新啟動
帶有 4.6 核心的 Debian Jessie(來自上次更新時的官方 jessie-backport)
軟體 MD raid 10
- 1 個用於 2 個 SSD 的 raid10 設備
- 1 個 raid10 設備用於 2 個 HDD
2 個 LVM VG 位於 2 個 RAID 設備之上
在 SSD_RAID10 VG 上的邏輯卷上創建的 bcache“記憶體”設備
在 HDD_RAID10 VG 上的邏輯卷上創建的 bcache“支持”設備
bcache 記憶體配置為寫回
工作量
許多詹金斯工作(持續集成)
CPU 密集型作業與 I/O 密集型時期混合
- 在使用 bcache 之前,I/O 平均延遲會定期上升超過 5 秒(!!!)
此伺服器上的實際工作負載僅在 1 年前開始(~2017 年 2 月)
根據 /proc/diskstats 在 bcache 設備上發出的 I/O 量)
- 350TB 寫入
- 6TB 讀取(我仔細檢查過,我認為大量的 RAM 有助於記憶體 VFS 層中的讀取)
結果
- 堅如磐石!機器無需重新啟動(正常執行時間 525 天),未檢測到損壞。
- 命中率高!78% 的歷史平均值,並在上升:過去幾個月超過 80%
- 回寫有很大幫助:磁碟延遲現在降低了一個數量級,遺憾的是我沒有準確的測量方法,但計算不再因寫入突發而停止。臟數據量上升到 5GB 以上,其中硬體 RAID 寫記憶體的大小通常在 512MB 和 1GB 之間)
結論
- bcache 在此配置上非常穩定(但 1 台機器,1 台配置,1 台機器年,不足以概括,但這是一個好的開始!)
- bcache 在此工作負載上非常高效,並且回寫模式似乎可以有效地替換硬體 RAID 寫記憶體(但請記住,電源損耗的可靠性尚未經過測試)
- 在我個人看來,bcache 被低估了,可以使用它打包有趣的解決方案,但還要注意原作者現在開發 bcachefs(基於 bcache 工作的文件系統)並且不再改進 bcache
我認為 SSD 儲存成本的降低以及可用選項的容量和範圍的增加為在需要的地方使用固態儲存提供了一個很好的案例,並放棄了選擇性(並且可能存在錯誤)記憶體的想法。
如果您填寫有關環境、容量需求和其他任何內容的詳細資訊,可能有助於獲得更好的答案。
我查看了您的連結並瀏覽了所有更新檔,並手動驗證了每個更新檔都已合併到 vanilla 核心 4.9.0 中,最後一個更新檔於 2016 年 10 月 27 日 04:31:17 UTC 合併。最後一個更新檔出現在 2016 年 12 月 11 日 19:17:54 UTC 發布的 4.9.0 中。而且它們都出現在從 16.04 向後移植的 Ubuntu 14.04 上可用的 4.4 核心中,
linux-lts-xenial_4.4.0-67.88
.而且我不會過多關注“SSD 儲存成本的降低”,因為 HDD 儲存成本也降低了。您仍然可以同時使用兩者來省錢。或者,您可以使用一些 NVMe 來代替 SSD,這會更快。
並且錯誤的損壞率可能仍然不是零,但即使存在錯誤,損壞率也足夠低,您不必擔心是否有備份,無論您使用記憶體還是襲擊。