BBWC：理論上は良い考えですが、データを保存したことはありますか？
私はBBWC（バッテリーバックアップ式書き込みキャッシュ）の目的に精通しています。以前は、UPSが良好であってもサーバーで使用していました。保護を提供しない明らかな障害があります。それが実際に実際の利益をもたらすかどうかを理解したいのですが。 （注：BBWCを使用しており、クラッシュ/障害が発生した人々からの応答、およびBBWCが回復に役立ったかどうかを特に探しています） 更新 ここでのフィードバックの後、私はBBWCが価値を付加するかどうかについてますます懐疑的になりました。 データの完全性について自信を持たせるために、ファイルシステムは、データが不揮発性ストレージ（必ずしもディスクではない-私が戻ってくるポイント）にコミットされたときを知っている必要があります。データがディスクにコミットされた時期について多くのディスクが存在することに注意してください（http://brad.livejournal.com/2116715.html）。ディスク上のキャッシュを無効にするとディスクがより正直になると想定するのは妥当と思われますが、これが当てはまるという保証もありません。 BBWCのバッファは通常非常に大きいため、バリアはディスクにより多くのデータをコミットする必要があるため、書き込みの遅延が発生します。一般的なアドバイスは、不揮発性ライトバックキャッシュを使用する場合はバリアを無効にすることです（そして、ディスクキャッシュ）。ただし、これは書き込み操作の整合性を損なうように見えます-不揮発性ストレージにより多くのデータが保持されているからといって、それがより一貫性があるということにはなりません。実際、論理的なトランザクション間の境界がなければ、一貫性を確保する機会は他の方法よりも少ないようです。 データが（ディスクにコミットされるのではなく）不揮発性ストレージに入る時点でBBWCがバリアを認識した場合、パフォーマンスを低下させることなくデータ整合性要件を満たしているように見えます-バリアを有効にする必要があることを意味します。ただし、これらのデバイスは通常、物理デバイスへのデータのフラッシュと一貫した動作を示し（バリアを使用すると大幅に遅くなります）、バリアを無効にするための広範なアドバイスを示すため、このように動作することはできません。何故なの？ OSのI / Oが一連のストリームとしてモデル化されている場合、書き込みキャッシュがOSによって管理されている場合、書き込みバリアのブロッキング効果を最小限に抑えるスコープがあります-このレベルでは論理トランザクション（単一のストリーム）コミットする必要があります。一方、トランザクションを構成するデータのビットがわからないBBWCでは、キャッシュ全体をディスクにコミットする必要があります。カーネル/ファイルシステムが実際にこれを実際に実装するかどうかは、現時点で投資しようと思っているよりもはるかに多くの努力を必要とします。 コミットされたことと突然の電源喪失をfibsに伝えるディスクの組み合わせは、間違いなく破損につながります。また、ジャーナリングまたはログ構造化ファイルシステムでは、停止後に完全なfsckを実行しないため、破損は言うまでもありませんそれを修復しようとしました。 故障モードに関しては、私の経験では、主電源の喪失（UPSと管理されたシャットダウンで簡単に軽減できる）が原因で、ほとんどの突然の停電が発生します。間違ったケーブルをラックから引き出すと、データセンターの品質が低下します（ラベル付けとケーブル管理）。UPSによって防止されない突然の電力損失イベントにはいくつかのタイプがあります-PSUまたはVRMの障害は、障害のあるBBWCが障害の場合にデータの整合性を提供しますが、そのようなイベントはどれくらい一般的ですか？ここでの回答の不足から判断して非常にまれです。 確かに、スタック内のフォールトトレランスを高くすると、BBWCよりもかなり高価になりますが、サーバーをクラスターとして実装すると、パフォーマンスと可用性に関して他にも多くの利点があります。 突然の電力損失の影響を軽減する別の方法は、SANを実装することです。AoEはこれを実用的な提案にします（iSCSIにはあまり意味がありません）が、やはりコストが高くなります。