已提議將 Btrfs 改進納入 Linux 6.2 核心中，以修復 RAID 5/6 實作中的寫入漏洞問題。 問題的本質在於，如果在記錄過程中發生崩潰，最初無法了解哪個RAID設備上的哪個區塊被正確寫入，以及哪個區塊沒有完成記錄。 如果在這種情況下嘗試恢復 RAID，則與寫入的區塊相對應的區塊可能會被破壞，因為 RAID 區塊的狀態不同步。 此問題發生在任何未採取特殊措施來消除這種影響的 RAID1/5/6 陣列中。
在 RAID 實作中，例如 btrfs 中的 RAID1，透過在兩個副本中使用校驗和來解決此問題；如果存在不匹配，則只需從第二個副本恢復資料即可。 如果某些設備開始發送不正確的資料而不是完全失敗，則此方法也適用。
然而，在RAID5/6 的情況下，檔案系統並未儲存奇偶校驗區塊的校驗和：在正常情況下，區塊的有效性透過它們都已校驗和的事實來驗證，而奇偶校驗區塊可以被重建從數據來看。 然而，在部分記錄的情況下，這種方法在某些情況下可能不起作用。 在這種情況下，當還原數組時，屬於不完整記錄的區塊可能會被錯誤地恢復。
對於 btrfs，如果產生的記錄小於條帶，則此問題最為相關。 在這種情況下，檔案系統必須執行讀取-修改-寫入操作（read-modify-write，RMW）。 如果遇到寫入不完整的區塊，則 RMW 操作可能會導致無論校驗和如何都無法偵測到的損壞。 開發人員進行了更改，RMW操作在執行此操作之前檢查區塊的校驗和，如果需要恢復數據，它還會在記錄後檢查校驗和。 不幸的是，在寫入不完整條帶（RMW）的情況下，這會導致計算校驗和的額外開銷，但會顯著提高可靠性。 對於RAID6來說，這樣的邏輯還沒準備好，但是對於RAID6中的這種故障，需要同時在2個裝置上寫入失敗，而這種可能性較小。
此外，我們還可以注意到開發人員對使用 RAID5/6 的建議，其本質是 Btrfs 中的元資料和資料儲存設定檔可能有所不同。 在這種情況下，您可以使用設定檔 RAID1（鏡像）甚至 RAID1C3（3 個副本）來儲存元數據，使用 RAID5 或 RAID6 來儲存資料。 一方面，這確保了可靠的元資料保護和不存在“寫入漏洞”，另一方面，也確保了更有效地利用空間，這是 RAID5/6 的特點。 這可以避免元資料損壞並可以糾正資料損壞。
還可以注意到，對於核心 6.2 中 Btrfs 中的 SSD，將預設啟動「丟棄」操作的非同步執行（標記不再需要實體儲存的釋放區塊）。 這種模式的優點是高效能，因為在佇列中對「丟棄」操作進行了有效分組，並由後台處理器對佇列進行進一步處理，這就是為什麼正常的FS 操作不會像同步「那樣」減慢速度。當區塊被釋放時，SSD 可以做出更好的決策。 另一方面，您將不再需要使用 fstrim 等實用程序，因為 FS 中的所有可用區塊都將被清除，無需額外掃描，也不會減慢操作速度。
來源： opennet.ru