web-dev-qa-db-ja.com

バリアのあるSATAドライブの書き込みキャッシュの安全性

SATAドライブに関する書き込みキャッシュ、NCQ、ファームウェアのバグ、バリアなどについて最近読んでいますが、電源障害が発生した場合にデータを安全に保つための最良の設定は何なのかわかりません。

私の理解では、NCQを使用すると、ドライブは書き込みを並べ替えてパフォーマンスを最適化すると同時に、物理的に書き込まれた要求をカーネルに通知し続けることができます。

書き込みキャッシュを使用すると、データが物理ディスクに書き込まれるのを待たないため、ドライブは要求をはるかに高速に処理できます。

ここでNCQと書き込みキャッシュがどのように混在するかわかりません...

ファイルシステム、特にジャーナル化されたものは、特定の要求がいつ書き留められたかを確認する必要があります。また、ユーザースペースプロセスはfsync()を使用して、特定のファイルのフラッシュを強制します。 fsync()の呼び出しは、データがディスクに書き込まれていることをファイルシステムが確認するまで戻らないはずです。

SASドライブでのみ見られる機能(FUA、Force Unit Access))があります。これは、ドライブにキャッシュをバイパスさせ、ディスクに直接書き込むことを強制します。それ以外には、書き込みバリアがあります。これは、カーネルが提供するメカニズムであり、ドライブのキャッシュフラッシュをトリガーできます。これにより、重要なデータだけでなくallキャッシュが強制的に書き込まれ、悪用された場合にシステム全体の速度が低下します。たとえば、fsync()を使用します。

次に、ファームウェアのバグがあるドライブ、またはデータが物理的に書き込まれたときに意図的に嘘をついているドライブがあります。

ドライブ/ファイルシステムをセットアップするにはいくつかの方法があります:A)NCQと書き込みキャッシュを無効にするB)NCQのみを有効にするC)書き込みキャッシュのみを有効にするD)NCQと書き込みキャッシュの両方を有効にする

バリアが有効になっていると思います。ところで、実際にバリアが有効になっているかどうかを確認するにはどうすればよいですか?

電力損失の場合、ディスクへのアクティブな書き込み中に、オプションB(NCQ、キャッシュなし)は、ファイルシステムジャーナルとデータの両方に対して安全であると思います。パフォーマンスが低下する可能性があります。

オプションD(NCQ +キャッシュ)は、バリアまたはFUAを使用している場合、fsync()を使用するファイルシステムジャーナルおよびアプリケーションにとって安全です。キャッシュで待機していたデータにとっては悪いことであり、それを検出するかどうかはファイルシステム次第であり(チェックサム)、少なくともファイルシステムが(うまくいけば)不安定な状態になることはありません。パフォーマンスに関しては、それはより良いはずです。

しかし、私の質問は立っています...私は何かが足りないのですか?考慮すべき他の変数はありますか?これを確認でき、ドライブが正常に動作することを確認できるツールはありますか?

13
julianjm

まっすぐなエンタープライズシステムの場合、ストレージアダプター(ほとんどの場合はRAIDカード)の形式で追加のレイヤーがあり、その上にさらに別のキャッシュレイヤーが存在します。最近のストレージスタックには多くの抽象化があり、私が行ったブログシリーズでこれについて詳しく説明しました Know your I/O

RAIDカードはディスク上のキャッシュをバイパスでき、その一部ではR​​AIDBIOSでこの機能を切り替えることもできます。これが、エンタープライズディスクがエンタープライズである理由の1つです。このファームウェアでは、コンシューマードライブ(、特に「緑」のドライブ)しないでください。この機能は、懸念されるケース、つまりコミットされていない書き込みによる電源障害に直接対処します。 RAIDカードのキャッシュは、バッテリーまたはフラッシュバックのいずれかである必要があり、電源が戻ってそれらの書き込みが再コミットされるまで保持されます。

特定のエンタープライズSSDには、完全に電源を切る前にオンボードキャッシュをコミットするのに十分な機能を備えたオンボードコンデンサが含まれています。

ディスクがマザーボードに直接接続されているシステムで作業している場合、保証は少なくなります。ディスク自体に書き込みキャッシュをコミットする機能がない限り、電源障害は実際に損失を引き起こします。 xfs ファイルシステムは、この障害モードだけでは生き残れないため、信頼性が低いという評判を得ました。これは、設計されたストレージの存続可能性を備えた完全なエンタープライズシステムで実行するように設計されています。

しかし、時が経ち、XFSはこれを乗り切るために設計されました。他の主要なLinuxファイルシステム(およびWindowsの ntfs )は、この非常に失敗したモードを乗り切るために、すでにエンジニアリングを行っていました。失われた書き込みはFSジャーナルに表示されず、コミットされなかったことがわかるため、破損が安全に検出され、回避されます。

ここで1つの問題を指摘します。それは、存在するディスクファームウェアです。この場合、FSジャーナルは現実に対して誤った仮定を行い、破損がしばらく検出されない可能性があります。パリティRAIDとミラーRAIDは、別のコミットされたコピーがあるはずなので、これを回避できます。ただし、単一ディスクのセットアップではクロスチェックが行われないため、実際にはエラーになります。

はるかに多くの検証を受ける(そして、想定されるワークロードパターンに対してテストされる)エンタープライズグレードのドライブを使用してファームウェアのリスクを回避し、そのような真実に耐えられるようにストレージシステムを設計します。

11
sysadmin1138

ファイルシステムジャーナルは、ドライブ書き込みキャッシュがないと想定して、メタデータへの書き込みを発行する前に、ジャーナルへの書き込みが完了するのを最初に待機していました。ドライブ書き込みキャッシュを有効にすると、この仮定が破られ、データが失われる可能性があります。したがって、障壁が作成されました。バリアを使用すると、ディスクが書き込みキャッシュを使用している場合でも、ジャーナルはメタデータへの書き込みの前にジャーナルへの書き込みが完了したことを確認できます。ディスクドライバレイヤーでは、ドライブに書き込みキャッシュがあり、有効になっているとドライブが報告したときに、後続のIOが送信される前に、バリアがディスクキャッシュのフラッシュを強制します。それ以外の場合、これは必要ありません。 、したがって、バリアは、前のIOが完了するまで、ドライブへの後続のIOの発行を防止します。NCQは、それ以上の待機が必要になる可能性があることを意味します。さらに発行する前に完了するための1つの保留中の要求。

3
psusi