BBWC：理論的には良い考えですが、データを保存したことはありますか？
私はBBWC（バッテリバックアップ式ライトキャッシュ）が何をするつもりなのかをよく知っています。以前は、UPSを使用していてもサーバーでそれらを使用していました。それが保護を提供しない明らかに障害があります。それが実際に実際に役立つかどうかを知りたいです。
（特に、BBWCを使用していてクラッシュ/障害が発生した人からの反応と、BBWCが回復を助けたかどうかを探しています）
更新
ここでのフィードバックの後、BBWCが何らかの価値を追加するかどうかについて、私はますます懐疑的になります。
データの整合性について何らかの信頼を得るために、ファイルシステムはデータが不揮発性ストレージにコミットされたときを知る必要があります（必ずしもディスクではありません-私が戻ってくるポイントです）。データがディスクにコミットされたときに多くのディスクが嘘をついていることは注目に値します（ http://brad.livejournal.com/2116715.html ）。ディスク上のキャッシュを無効にすると、ディスクがより正直になる可能性があると想定するのが妥当だと思われますが、これが事実であるという保証はまだありません。
BBWCのバッファは通常大きいため、バリアはディスクにコミットするデータを大幅に増やす必要があるため、書き込みに遅延が発生する可能性があります。一般的なアドバイスは、不揮発性ライトバックキャッシュを使用する場合はバリアを無効にすることです（およびディスクキャッシング）。ただし、これは書き込み操作の整合性を損なうように見えます。不揮発性ストレージでより多くのデータが維持されるからといって、データの一貫性が向上するわけではありません。実際、間違いなく論理トランザクション間の境界がないと、他の方法よりも一貫性を確保する機会が少ないようです。
データが（ディスクにコミットされるのではなく）不揮発性ストレージに入る時点でBBWCがバリアを確認する場合、パフォーマンスを低下させることなくデータ整合性要件を満たしているように見えます。つまり、バリアを引き続き有効にする必要があります。ただし、これらのデバイスは一般に、物理デバイスへのデータのフラッシュと一貫した動作（バリアを使用すると大幅に遅くなる）とバリアを無効にするための広範なアドバイスを示すため、このように動作することはできません。何故なの？
OSのI/Oが一連のストリームとしてモデル化されている場合、書き込みキャッシュがOSによって管理されている場合、書き込みバリアのブロック効果を最小限に抑えるためのスコープがあります-このレベルでは論理トランザクション（単一のストリーム）のみ）コミットする必要があります。一方、トランザクションを構成するデータのビットを認識していないBBWCは、キャッシュ全体をディスクにコミットする必要があります。カーネル/ファイルシステムが実際にこれを実際に実装するかどうかは、現時点で投資するよりもはるかに多くの労力が必要になります。
コミットされたものについての虚偽を伝えるディスクと突然の電源喪失が間違いなく破損につながるディスクの組み合わせ-停止後、完全な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
つまり、"ねえ、リブート/停電後も存続したデータが書き込みキャッシュにあります!!これをディスクに書き戻します!! "
興味深いケースは、-tornado中に電源を失ったシステムの死後のことでした。配列のシーケンスは次のとおりです。
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 Accelerator
1793 POSTエラーは一意です。-システムの使用中に、データがアレイアクセラレータのメモリにあるときに電力が遮断されました。ただし、これは竜巻であったため、電力は4日以内に復元されないため、アレイのバッテリーが消耗しましたサーバー内のRAIDコントローラーは2つあります。もう1つのコントローラーには、バッテリーよりはるかに長持ちするFBWCユニットがあり、そのドライブは適切に回復しました。空のバッテリーによってバックアップされたアレイで、データの破損が発生しました。
施設では十分なバッテリー稼働時間にもかかわらず、電力と危険な条件がない4日間は、誰もサーバーを安全にシャットダウンすることを不可能にしました。 
はい、そのケースがありました。
データセンター内のサーバー（「UPSなし」）（データセンターにUPSがある）。 PDU障害-システムが激しくクラッシュしました。データの損失はありません。
そして、それは基本的にそれです。 BBWCの良いところは、それがマシンにあるということです。 UPSを持っている-私を信じて、時々誰かが愚かなことをする（間違ったケーブルを引くなど）。 UPSは外付けです。ああ、そのケーブル;）
これは質問に対する2番目の答えを必要とするようです...
スタンドアロンのVMware ESXiホストでRAID 5アレイのドライブを紛失してしまいました。低下したアレイは、VMおよびアプリケーションレベルでのパフォーマンスに影響を与えました。
Smart Array P410i in Slot 0 (Embedded) (sn: 5001438011138950)
array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)
この会社のIT担当者は、ドライブが故障してサーバーをハードリセットしたことを認識していませんでした（それをすべて改善するために）。
負荷の高い仮想マシンが上で実行されている侵害されたアレイに対してこれを行うことの興味深い効果は次のとおりです。
キャッシュステータスの詳細：現在のアレイコントローラーは、最後にリセットされたとき、または電源が投入されたときに、バッテリー/コンデンサー付きの書き込みキャッシュに有効なデータが格納されていました。これは、システムが正常にシャットダウンされなかった可能性があることを示しています。アレイコントローラーは、このデータをドライブに自動的に書き込むか、または書き込みを試みました。このメッセージは、アレイコントローラの次のリセットまたは電源の再投入まで表示され続けます。
したがって、システムが突然停止した場合でも、処理中のデータはBBWCによって保護されていました。仮想マシンはすべて適切に復旧し、システムは現在良好な状態です。
HW RAIDコントローラーのバッテリーバックアップ式キャッシュが完全に失敗した2つのケースがあります（2つの別の会社で）。
BBCはバッテリーが機能するという驚くべき考えに依存しています。問題は、ある時点でコントローラーのバッテリーが故障し、破壊的なのは、多くのHW RAIDコントローラーで故障することですサイレント。電力損失から保護されたキャッシュがあると思っていましたが、そうではありませんでした。
停電時には、RAIDアレイのデータ損失が広範囲に及ぶため、すべてのディスクの内容が回復不能になりました。すべてが失われました。ケースの1つには、完全にテスト専用のマシンが含まれていました。
その後、「もう二度と」と言って、電力損失に対する適切な回復力（ext4）を持つLinux +ジャーナルベースのfsでソフトウェアベースのディスクミラーリング（mdadm）に切り替え、振り返ることはありませんでした。確かに、私は極端に高いIO使用率がなかったサーバーでそれを使用しました。
「データの保存」に加えて、他のことにも役立ちます。また、（キャッシュ内の）書き込みのバッファリングにも優れているため、ディスク書き込みキューを低く保つことでIOサブシステムのパフォーマンスを向上させることができます。これは、インタラクティブパフォーマンスが必要なサーバーでは特に重要です。最重要事項-たとえば、Citrix XenAppやWindowsターミナルサービス。
これは、Webサーバーやファイルサーバーにとってそれほど重要ではありません。少し遅れて気づかない、または慣れている場合もあります。ただし、Officeアプリケーションのアイコンをクリックすると、応答性が期待できます。 CEOも同様です。