web-dev-qa-db-ja.com

SATAディスクの書き込みキャッシュを安全にする

おそらく（たとえば、 ここでの質問 を参照）、NCQが有効なドライブでは、ドライブの書き込みキャッシュは安全であると考えられます。これは、コミットされるデータについてOSに嘘をつかないためです。そうでないときはプラッター。これを実現するために必要な設定を理解しようとしています。

diskchecker.pl を使用して、すべてのブロックが電源プラグの引きに耐えられるかどうかを確認しています。サーバーは次のように構成されています。

  • Linux MDRAID10で実行されている4xST3500514NS。 Intel3420チップセット。 AHCIモードの場合。
  • RAID10で実行されているLVM。
  • テストされたファイルシステムは、論理ボリューム上でext4（バリア= 1、データ=順序付き）です。また、論理ボリューム（ブロックデバイス）で直接テストしてみました。それは助けにはならなかった。
  • Debian 6.0（スクイーズ）;カーネル2.6.32-5-AMD64

書き込みキャッシュ（hdparm -W0）をオフにすると、機能します（パフォーマンスが大幅に低下します）。したがって、上位層は機能しているようです。

LibataでFUAを有効にしてみました（モジュールの読み込みにfua=1を渡し、dmesgで確認しました）が、役に立ちませんでした。

これを機能させる方法について何か提案はありますか？

編集：理由を見つけました（私の答えを参照してください）;パフォーマンスの少なくとも一部を取り戻す方法について何か提案はありますか？

linuxraidcachesatadata-integrity
6
derobert

カーネル2.6.38-2-AMD64（sidから）にアップグレードすると、パフォーマンスが大幅に低下しますが（書き込みキャッシュをオフにするのと非常によく似ています）、問題が修正されます。

これについて調査を行ったところ、MDは2.6.33-rc1（commit a2826aa92e2e14db372eda01d333267258944033）までI/Oバリア（RAID1を除く）をサポートしていなかったようです。

3
derobert

ええ、これが安全であるためのコストであると私が知っていることについては、Postgresqlメーリングリストのすべてのファイルシステムとストレージレイヤーでデータの安全性と速度のコストに関する多くのスレッドを見ることができます。小さなメモリが接続されているVertex2Proまたは最後のSSDintelシリーズ（レイドコントローラーのバッテリーキャッシュなど）はデータベースで安全に使用でき、SSDの問題は書き込みキャッシュを無効にすることで修正できません。

ここに2つのリンクを貼り付けますが、メーリングリストに複数の例があります。検索してください。

http://archives.postgresql.org/pgsql-performance/2010-06/msg00076.php

http://archives.postgresql.org/pgsql-general/2011-04/msg00709.php

3
skuda21

そのため、BBU（バッテリーバックアップユニット）を備えたハードウェアRAIDコントローラーを実際に使用する必要があります。そうすれば、書き込みキャッシュをオンにして安全にすることができます。

1
wazoox