Linuxスワップのサイレントディスクエラーと信頼性

私の理解では、ハードドライブとSSDはドライブ内にいくつかの基本的なエラー修正を実装しており、ほとんどのRAID構成（例：mdadm）はこれに依存して、ドライブがエラーを修正できず、オフラインにする必要がある時期を決定します。ただし、これは、ストレージのエラー診断が100％正確であることによって異なります。そうではなく、2ドライブのRAID-1ミラーのような一般的な構成は脆弱です。1つのドライブの一部のビットが警告なしで破損し、ドライブが読み取りエラーを報告しないとします。したがって、btrfsやZFSのようなファイルシステムは、バグのあるドライブファームウェアや問題のあるSATAケーブルなどを信頼しないように、独自のチェックサムを実装します。

同様に、RAMにも信頼性の問題があるため、この問題を解決するためのECC RAMがあります。

私の質問はこれです：Linuxスワップファイルを2つのディスク構成のドライブファームウェア（つまりメインラインカーネルドライバーを使用して）でキャッチされないサイレント破損/ビット腐敗から保護する正規の方法は何ですか？ここでエンドツーエンドの保護が不足している構成（btrfsによって提供される構成など）は、ECC RAMによってもたらされる安心感を多少打ち消しているように思えます。しかし、私は良い方法を考えることができません：

• btrfsはスワップファイルをまったくサポートしていません。あなたはbtrfsファイルからループデバイスをセットアップし、それをスワップすることができます。しかし、それには問題があります：
  • ランダム書き込みはうまく機能しません：https : //btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • コピーオンライトを無効にする提案があると、チェックサムも無効になるため、この演習の全体のポイントは無効になります。彼らの前提は、データファイルには独自の内部保護があるということです。
• ：LinuxでのZFSは、私は仕事ができると思いスワップ、としてZVOLを使用可能にhttp://zfsonlinux.org/faq.html#CanIUseaZVOLforSwapしかし、私の読書から、ZFSは、通常、メモリに要求している、そしてそれは、スワップで働い取得します- -のみのアプリケーションは、それを理解するいくつかの仕事のように聞こえます。これは私の最初の選択ではないと思います。信頼できるスワップを行うためだけにツリー外のカーネルモジュールを使用する必要がある理由は、私を超えています-今日の時代のほとんどの最新のLinuxディストリビューション/カーネルでこれを実現する方法は確かにありますか？
• 私はこの質問に議論正確な理由のために、メモリマネージャ自体の中にチェックサムを有効にするには、パッチが適用されたLinuxカーネルのメーリングリストのスレッド、実際にありました： http://thread.gmane.org/gmane.linux.kernel/989246は -残念ながら、私の知る限りでは、パッチは停止し、私には知られていない理由により、アップストリームに到達しませんでした。残念ながら、それは素晴らしい機能のように思えました。一方、RAID-1にスワップを配置する場合-破損がチェックサムの修復能力を超えている場合、パニックまたは何かの前に、メモリマネージャーが他のドライブから読み取ろうとする必要があります。おそらく、メモリマネージャが行うべきことの範囲外です。

要約すれば：

• RAMにはECCがあり、エラーを修正します
• 永続ストレージ上のファイルには、エラーを修正するためのbtrfsがあります
• スワップには??? <---これは私の質問です

ストレージハードウェアにはチェックサムやCRCなどがあるため、スワップから取得したデータの整合性を信頼しています。

上記のコメントの1つで、次のように言います。

true、しかしそれはディスク自体の外側のビットフリップから保護しません

「それ」はここでディスクのチェックサムを意味します。

それは事実ですが、SATAはコマンドとデータに32ビットCRCを使用します。したがって、ディスクとSATAコントローラーの間でデータを検出不能に破損する可能性は、40億分の1です。つまり、継続的なエラーソースは125 MiBの転送ごとに頻繁にエラーを引き起こす可能性がありますが、宇宙線などのまれなランダムエラーソースは、検出できないエラーをほとんど発生しません。

また、転送された125 MiBあたり1近くの割合で未検出エラーの原因となるソースがある場合、再転送を必要とする検出されたエラーの数が多いため、パフォーマンスがひどくなることにも注意してください。監視とロギングにより、検出されていない破損を回避するために、時間内に問題を警告する可能性があります。

記憶媒体のチェックサムに関しては、すべてのSATA（およびその前のPATA）ディスクは、セクターごとのチェックサムを使用します。「エンタープライズ」ハードディスクの特徴的な機能の1つは、追加のデータ整合性機能によって保護された大きなセクターであり、検出されないエラーの可能性を大幅に低減します。

このような対策がなければ、すべてのハードドライブのスペアセクタープールに意味がありません。ドライブ自体が不良セクターを検出できなかったため、新しいセクターを入れ替えることはできませんでした。

別のコメントで、あなたは尋ねます：

SATAが非常に信頼できる場合、ZFS、btrfs、ReFSなどのチェックサムファイルシステムがあるのはなぜですか？

一般的に言って、長期的にデータを保存するようにスワップを要求するのではありません。スワップストレージの制限はシステムの稼働時間であり、スワップ内のほとんどのデータはそれほど長くは持続しません。システムの仮想メモリシステムを通過するほとんどのデータは、存続期間の非常に短いプロセスに属しているためです。

それに加えて、カーネルとlibc更新、仮想化、クラウドアーキテクチャなどの頻度が増加するにつれて、アップタイムは一般的に長年にわたって短くなっています。

さらに、スワップ内のほとんどのデータは、適切に管理されたシステムでは本来使用されず、メインRAMが不足することはありません。そのようなシステムでは、スワップが発生するのは、プログラムが頻繁に使用しないページです。これは、想像よりも一般的です。プログラムがリンクするほとんどの動的ライブラリには、プログラムが使用しないルーチンが含まれていますが、動的リンカーによってRAMにロードする必要がありました。OSは、ライブラリ内のすべてのプログラムテキストを使用していないことを検出すると、それをスワップアウトして、プログラムが使用しているコードとデータのためのスペースを作ります。そのようなスワップアウトされたメモリページが破損している場合、誰が知っているでしょうか。

これは、データが永続的かつ永続的に保存されることが期待されるZFSなどとは対照的です。これにより、システムの現在の稼働時間だけでなく、ストレージシステムを構成する個々のストレージデバイスの寿命を超えて持続します。ZFSなどは、スワップによって解決される問題よりも約2桁長い時間スケールで問題を解決しています。したがって、ZFSではLinuxスワップよりもはるかに高い破損検出要件があります。

ZFSなどは、スワップとは別の重要な点で異なります。ファイルシステムをRAIDスワップすることはありません。場合は、複数のスワップデバイスが単一のマシン上で使用されている、それはだJBODのないRAID-0以上のように、スキーム。（例：macOSのチェーンスワップファイルスキーム、Linux swaponなど）交換用デバイスに保存するデータ。ZFS用語では、スワップデバイスを他のストレージデバイスの冗長コピーから再同期化しません。

これはすべて、信頼できるスワップデバイスを使用する必要があることを意味します。私はかつて$ 20の外付けUSB HDDエンクロージャーを使用して、問題のあるZFSプールを救助しましたが、エンクロージャー自体が信頼できないことを発見しただけで、独自のエラーがプロセスに導入されました。ZFSの強力なチェックサム機能は、私をここに救いました。スワップファイルを使用したスト​​レージメディアのこのような無頓着な扱いを回避することはできません。スワップデバイスが故障していて、転送される125 MiBごとに検出不可能なエラーが発生する可能性がある最悪のケースに近づいている場合は、できるだけ早く交換する必要があります。

この質問におけるパラノイアの全体的な感覚は、ビザンチン将軍の問題の事例に委ねられています。それを読んで、コンピューターサイエンスの世界に問題を説明している学術論文で1982年の日付を熟考し、2019年に、この問題に追加する新鮮な考えがあるかどうかを判断してください。そうでない場合は、ビザンチン将軍問題についてすべて知っている30年間のCS卒業生が設計したテクノロジーを使用することになるでしょう。

これはよく踏みにじられた地です。コンピューターサイエンスジャーナルでまだ死ぬまで議論されていないアイデア、異論、または解決策を思い付くことはできないでしょう。

SATAは確かに完全に信頼できるわけではありませんが、アカデミアやカーネル開発チームの1つに参加するのでない限り、ここに最新技術を大幅に追加することはできません。ZFS、btrfs、ReFS ...すでに述べたように、これらの問題はすでに手元にあります。OSユーザーは、OSの作成者がこれらの問題に対応していることを信頼する必要があります。ビザンチン将軍について。

現在のところ、スワップファイルをZFSまたはBtrfsの上に置くことは現実的ではありませんが、上記の方法で安心できない場合は、少なくともxfsまたはext4の上に置くことができます。専用のスワップパーティションを使用するよりも良いでしょう。

dm-integrity

参照：Documentation / device-mapper / dm-integrity.txt

dm-integrity通常、ジャーナリングモードで使用されます。スワップの場合、ジャーナリングなしで行うように手配できます。これにより、パフォーマンスのオーバーヘッドが大幅に低下する可能性があります。クリーンでないシャットダウン後のエラーのキャッチを回避するために、各ブートでswap-over-integrityパーティションを再フォーマットする必要があるかどうかはわかりません。

の最初の発表でdm-integrity、著者は代わりに「上位レベルのデータ整合性保護」を優先することを述べています。スワップの場合、それはチェックサムをRAMに保存する可能性を開きます。ただし、このオプションでは、現在のスワップコードに重要な変更を加える必要があり、メモリ使用量が増加します。（現在のコードトラックは、個々のページ/セクターではなく、エクステントを使用して効率的にスワップします）。

DIF / DIX？

DIXサポートは、OracleによってLinux 2.6.27（2008）で追加されました。

DIXを使用すると、エンドツーエンドの整合性が提供されますか？

あなたはあなたのベンダーに相談することができます。彼らがそれについて嘘をついているかどうか、どうやってわかるかわかりません。

OS（オペレーティングシステム）とHBAの間で転送中のデータを保護するには、 DIXが必要です。

DIFはそれ自体で、HBAとストレージデバイス間のデータの保護を強化します。（参照：エラー率の違いに関するいくつかの数値を含むプレゼンテーション）

ガードフィールドのチェックサムが標準化されているため、保存されているデータを保護することなく、DIXコマンドを実装することが技術的に可能です。HBA（またはストレージデバイス）に読み取り時にチェックサムを再生成させるだけです。この見通しは、元のDIXプロジェクトによって非常に明確になりました。

• DIF / DIXは論理ブロックチェックサムに 直交
  • 私たちはまだあなたを愛しています、btrfs！
  • 論理ブロックチェックサムエラーは、破損したデータの検出に使用されます
  • 検出は読み取り時に行われます
  • ...数か月後になる可能性があり、元のバッファが失われます
  • 元のバッファーが文字化けしていた場合、冗長コピーも悪い可能性があります
• DIF / DIXは、破損を予防的に防止するためのものです。
  • 不良データが最初からディスクに保存されるのを防ぐ
  • ...そして、元のバッファがメモリから消去される前に問題について調べる

- oss.oracle.comからlpc08データ-integrity.pdf

DIXに関する初期の投稿の1つは、ドライブがDIFをサポートしていない場合でも、OSとHBAの間でDIXを使用する可能性について言及しています。

DIXが現在使用されている「エンタープライズ」のコンテキストでは、完全な危険性は比較的ありそうにありません。人々はそれに気づくでしょう。また、DIFは、520バイトのセクターでフォーマットできる既存のハードウェアに基づいていました。DIFを使用するためのプロトコルでは、最初にドライブを再フォーマットする必要があるとされていますsg_format。たとえばコマンドを参照してください。

より可能性が高いのは、真のエンドツーエンドの原則に従っていない実装です。一例を挙げると、CPUサイクルを節約するためにDIXのより弱いチェックサムオプションをサポートするベンダーが言及されています。これは、スタックのさらに下にあるより強力なチェックサムに置き換えられます。これは便利ですが、完全なエンドツーエンドの保護ではありません。

または、OSが独自のチェックサムを生成し、アプリケーションタグスペースに保存することもできます。ただし、現在のLinux（v4.20）では、これはサポートされていません。2014年に書かれたコメントは、これは「アプリケーションタグスペースの使用を実際に許可するストレージデバイスが非常に少ないため」であることを示唆しています。（これがストレージデバイス自体、HBA、またはその両方のどちらを指しているのかはわかりません）。

Linuxで動作するDIXデバイスにはどのようなものがありますか？

データと整合性メタデータバッファーの分離、およびチェックサムでの選択は、データ整合性拡張[DIX]と呼ばれます。これらの拡張はプロトコル本体（T10、T13）の範囲外であるため、OracleとそのパートナーはStorage Networking Industry Association内で標準化を試みています。

- v4.20 /ドキュメント/ブロック/データintegrity.txt

ウィキペディアによれば、DIFはNVMe 1.2.1で標準化されています。SCSI HBAの場合、ポイントする標準がないと、これを特定するのが少し難しいようです。現時点では、「Linux DIX」のサポートについて話すのが最も正確かもしれません:-)。利用可能なデバイスがあります：

SCSI T10 DIF / DIX [sic]は、ハードウェアベンダーが認定し、特定のHBAおよびストレージアレイ構成を完全にサポートしている場合、Red Hat Enterprise Linux 7.4で完全にサポートされます。DIF / DIXは他の構成ではサポートされておらず、ブートデバイスでの使用はサポートされていません。また、仮想化ゲストではサポートされていません。

現在、このサポートを提供しているベンダーは次のとおりです...

- RHEL 7.5リリースノート、第16章ストレージ

RHEL 7.5リリースノートに記載されているハードウェアはすべてファイバーチャネルです。

私はこの市場を知りません。DIXは将来、サーバーでより広く利用できるようになると思われます。私がそれが消費者のSATAディスクで利用可能になる理由を私は知りません-私が知っている限り、コマンド形式の事実上の標準さえありません。NVMeでより広く利用できるようになるかどうかに興味があります。

スワップには??? <---これは私の質問です

スワップはLinuxではまだ保護されていません（ただし、UPDを参照）。

もちろん、Linuxにはスワップストレージとして機能するZFS がありますが、状況によっては依然としてロックアップが存在するため、そのオプションを効果的に無効にできます。

Btrfsはまだスワップファイルを処理できません。ループバックの使用の可能性について言及していますが、パフォーマンスが低いことが指摘されています。Linux 5がついにそれを手に入れることができるかどうか不明な兆候があります（？）…

従来のスワップ自体をチェックサムで保護するパッチは、主流になりませんでした。

つまり、オールインオール：いいえ。Linuxにはまだギャップがあります。

UPD。：@sourcejediが 指摘しているように、dm-integrityなどのツールがあります。バージョン4.12以降のLinuxカーネルは、デバイスマッパーのターゲットを取得しました。これは、任意の一般的なブロックデバイスにチェックサムを提供するために使用でき、スワップ用のものも例外ではありません。ツールは主要なディストリビューションに広く組み込まれていません。それらのほとんどはudevサブシステムでサポートされていませんが、最終的には変更されるはずです。冗長プロバイダーとペアにすると、たとえばLinuxソフトウェアRAIDのMDの上に置くと、dm-integrityが問題とMDが処理する必要があります。

「標準的な」方法があるとは思わないので、以下は私の個人的な意見です。

潜在的なユーザーの観点からbtrfsの進歩を監視したので、私にはそれがどういうわけかまだ曖昧であると言わざるを得ません。成熟していて本番環境で使用できる機能と、一見未熟で危険な機能があります。

個人的には、使用する機能と使用しない機能を決定する時間はありません。これらの機能をオフまたはオンにする方法を理解するために必要な時間を逃してください。

対照的に、ZFSは堅実で成熟しています（IMHO）。したがって、あなたの質問に答えるために、私はZFSを使用します（ちなみに、それは多くのメモリを消費しません-下記を参照してください）。

しかし、あなたにとっては、btrfsは既に使用しているので（私が正しい場合）、正しい選択かもしれません。上記のコメントの1つは、スワップに使用する方法を示しています。

たまたま、私は最後の数日間、いくつかのLinuxサーバーをZFSに置きました。そのたびに、ルートファイルシステムとスワップが含まれています。これを行う前に、私は非常に徹底的にいくつかの研究を行いました、それは私に数日かかりました。私が学んだことの短い要約：

ZFSのメモリ消費

ZFSのメモリ消費に関する一般的な誤解があります。ZFSは通常、多くのメモリを消費しません。実際、2 GBのRAMを搭載したマシンでは、TBのストレージで動作します。デデュプリケーション（デフォルトではオフ）を使用する場合のみ、大量のRAMが必要になります。

ハードウェアエラーの検出/修正

SATA、PATA、RAID、またはその他のエラー検出/修正メカニズムがデータの完全性に十分であるかどうかは、ネット上のあらゆる場所で無限の議論や炎上さえ引き起こされる問題です。理論的には、ハードウェアストレージデバイスは発生したエラーを報告し（場合によっては修正し）、すべてのレベル（チップセット、メモリなど）のデータ転送ハードウェアも同様に報告する必要があります。

まあ、すべての場合に対応するわけではないか、エラーに対して驚くほど反応します。例として、典型的なRAID5構成を考えてみましょう。通常、1つのディスクに問題がある場合、それはRAIDに報告し、RAIDは他のディスクから読み取られるデータを構築して渡しますが、障害のあるディスクに書き戻します（これにより、おそらくデータを書き込む前のセクター）; 同じディスクから報告されたエラーが多すぎる場合、RAIDはそれをオフラインにし、管理者に通知します（正しく構成されている場合）。

これまでのところ、問題はありませんが、ディスクからエラーが報告されずに、障害のあるデータがディスクから取り出される場合があります（次のセクションを参照）。ほとんどのRAIDは、パリティ情報を使用してこの状況を検出できますが、その反応は愚かです。エラーを報告してデータが渡されないようにする代わりに、障害のあるデータに基づいてパリティを再計算し、新しいパリティをそれぞれに書き込みますこれにより、障害のあるデータに永久に正しいマークが付けられます。

それは合理的な行動ですか？私の知る限り、ほとんどのハードウェアRAID5コントローラーとLinuxのmd RAIDもこのように動作します。

私はbtrfsのエラー修正については知りませんが、特にbtrfsのRAIDを使用している場合は、最終的にもう一度ドキュメントを注意深く読む必要があります。

サイレントビット腐敗

すべての炎上戦争と（疑似）科学的議論にもかかわらず：現実はほとんど理論とは異なり、理論は反対のことを述べているかもしれませんが、サイレントビット腐敗は確実に発生します（通常、サイレントボット腐敗は、ストレージデバイスがデータを報告せずにハードウェアストレージ上のデータが破損することを意味しますこのデータが読み取られるとエラーになりますが、この定義には送信パスの任意の場所にフリッピングビットを追加します）。

これが発生するのは私の個人的な意見ではありません。少なくとも、Google、Amazon、CERNはその主題を正確にカバーする詳細なホワイトペーパーを公開しています。論文は無料で無料でダウンロードできます。彼らは、数百万のハードディスクと数十万のサーバー/ストレージデバイスを使って体系的な実験を行いました。これは、データの破損が検出されないという問題があったか、発生する前にそれを防ぐために何をすべきかを知りたかったためです。

要約すると、サーバーファーム内のデータは、MTBF統計または他の理論で予想されるよりもはるかに高い割合で破損していました。大幅に高いということは、桁違いのことです。

したがって、無音のビット腐敗、つまり、伝送経路の任意の時点で検出されないデータ破損は、現実の問題です。

データの寿命

スワップデータの寿命は短いと彼が言ったとき、ウォーレン・ヤングは正しいです。しかし、私は次の考慮事項を追加したいと思います：（ドキュメントの意味での）データがスワップに入るだけでなく、O / Sまたは他の実行中のソフトウェアの一部（おそらくそれ以上）が入れられます。私がMP3をスワップしている場合、私はフリッピングビットに耐えることができます。（極端な状況が原因で）本番httpdサーバーソフトウェアの一部がスワップされている場合、ビットが反転することに耐えられず、検出されない場合、破損したコードの実行につながります。

エピローグ

私にとって、ZFSはこれらの問題を解決します。より正確には、ディスクからメモリに移動し、サイレントビットが回転する確率を桁違いに減らします。さらに、適切に構成されている場合（つまり、RAIDの代わりにミラー）、期待どおりに機能し、結局簡単に理解できるクリーンで合理的なエラー修正を提供します。

とはいえ、絶対に安全を確保することはできません。個人的には、ECC RAMをディスクよりも信頼しており、エンドツーエンドのチェックサムを備えたZFSにより、問題の確率が桁違いに減少すると確信しています。ただし、ECC RAMなしでZFSを使用することはお勧めしません。

免責事項：ZFSベンダーや開発者とは一切関係ありません。これは、ZFSのすべてのバリアント（フォーク）に当てはまります。私は過去数日でそれのファンになりました...