BBWC：理論上是個好主意，但有人保存過你的數據嗎？
我很熟悉 BBWC（電池支持的寫入記憶體）的用途 - 並且以前在我的伺服器中使用過它們，即使是好的 UPS 也是如此。顯然存在它不提供保護的故障。我很想知道它是否真的在實踐中提供了任何真正的好處。
（注意，我專門尋找那些有 BBWC 並且發生過崩潰/故障的人的回應，以及 BBWC 是否有助於恢復）
更新
在這裡得到回饋後，我越來越懷疑 BBWC 是否會增加任何價值。
為了對數據完整性有任何信心，文件系統必須知道數據何時被送出到非易失性儲存（不一定是磁碟——我將回到這一點）。值得注意的是，很多磁碟都謊報數據何時送出到磁碟 ( http://brad.livejournal.com/2116715.html )。雖然假設禁用磁碟記憶體可能會使磁碟更誠實似乎是合理的，但仍然不能保證情況確實如此。
由於 BBWC 中的緩衝區通常很大，屏障可能需要將更多數據送出到磁碟，因此會導致寫入延遲：一般建議是在使用非易失性回寫記憶體時禁用屏障（並禁用 on-磁碟記憶體）。然而，這似乎會破壞寫操作的完整性——僅僅因為更多的數據保存在非易失性儲存中並不意味著它會更加一致。事實上，可以說如果邏輯事務之間沒有分界，那麼確保一致性的機會似乎比其他方式少。
如果 BBWC 在數據進入其非易失性儲存（而不是送出到磁碟）時確認障礙，那麼它似乎滿足了數據完整性要求而沒有性能損失——這意味著仍然應該啟用障礙。然而，由於這些設備通常表現出與將數據刷新到物理設備一致的行為（使用屏障顯著變慢）以及禁用屏障的廣泛建議，因此它們不能以這種方式表現。為什麼不？
如果作業系統中的 I/O 被建模為一系列流，那麼當寫入記憶體由作業系統管理時，就有一些範圍可以最小化寫屏障的阻塞效應 - 因為在這個級別上只有邏輯事務（單個流) 需要送出。另一方面，不知道哪些數據位構成事務的 BBWC 將不得不將其整個記憶體送出到磁碟。核心/文件系統是否真正在實踐中實現這一點需要比我目前願意投資的更多的努力。
告訴fibs關於已送出的內容和突然斷電的磁碟組合無疑會導致損壞 - 並且在中斷後不執行完整fsck的日誌或日誌結構化文件系統不太可能檢測到損壞更不用說試圖修復它。
就故障模式而言，根據我的經驗，大多數突然停電都是因為失去主電源（通過 UPS 和管理關機很容易緩解）。人們將錯誤的電纜從機架中拉出意味著數據中心衛生狀況不佳（標籤和電纜管理）。UPS 無法防止某些類型的突然斷電事件 - PSU 或 VRM 中的故障 帶有屏障的 BBWC 將在此處發生故障時提供數據完整性，但是此類事件有多常見？從這裡沒有回應來看，非常罕見。
當然，在堆棧中將容錯移到更高的位置比 BBWC 的成本要高得多——但是將伺服器作為集群實現對於性能和可用性還有很多其他好處。
減輕突然斷電影響的另一種方法是實施 SAN——AoE 使這成為一個實際的提議（我真的不明白 iSCSI 的意義），但成本也更高。
當然。我有電池支持的記憶體 (BBWC) 和後來的快閃記憶體支持的寫記憶體 (FBWC)，可以在崩潰和突然斷電後保護飛行中的數據。
在 HP ProLiant 伺服器上，典型消息是：
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator這意味著，“嘿，寫入記憶體中有數據在重新啟動/斷電後倖存下來！！我現在要把它寫回磁碟！！ ”
一個有趣的案例是我對在龍捲風期間斷電的系統進行的事後分析，數組序列是：
POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss POST Error: 1779-Drive Array Controller Detects Replacement Drives POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator1793 POST 錯誤是唯一的。- 系統在使用時，數據在陣列加速器記憶體中時電源中斷。但由於是龍捲風，四天之內都沒有恢復供電，所以陣列電池耗盡，裡面的數據也失去了。伺服器有兩個 RAID 控制器。另一個控制器有一個 FBWC 單元，它的使用壽命比電池長得多。該驅動器正確恢復。由空電池支持的陣列導致一些數據損壞。
儘管該設施有充足的電池執行時間，但四天沒有電力和危險條件使得任何人都無法安全關閉伺服器。
