スワップから取得したデータの整合性を信頼しています。ストレージ ハードウェア チェックサム、CRC などがあります。
上記のコメントの 1 つで、あなたは次のように述べています。
<ブロック引用>true ですが、ディスク自体の外側でのビット フリップは保護されません
「それ」はディスクのチェックサムを意味します。
その通りですが、SATA はコマンドとデータに 32 ビット CRC を使用します。したがって、40 億分の 1 の確率で、ディスクと SATA コントローラーの間で検出できないほどデータが破損する可能性があります。つまり、継続的なエラー ソースは、転送される 125 MiB ごとにエラーを発生させる可能性がありますが、宇宙線のようなまれなランダム エラー ソースは、ごくわずかな割合で検出不可能なエラーを引き起こす可能性があります。
また、転送される 125 MiB あたり 1 つに近い割合で検出されないエラーを引き起こすソースがある場合、パフォーマンスはひどいものになることにも注意してください。 検出の数が多いため 再転送が必要なエラー。監視とログ記録により、検出されない破損を回避するために、時間内に問題が警告される可能性があります。
ストレージ メディアのチェックサムに関しては、すべての SATA (およびそれ以前の PATA) ディスクは、ある種のセクターごとのチェックサムを使用します。 「エンタープライズ」ハードディスクの特徴の 1 つは、追加のデータ整合性機能によって保護されたより大きなセクターであり、検出されないエラーの可能性を大幅に減らします。
このような対策がなければ、すべてのハード ドライブにスペア セクター プールを用意しても意味がありません。ドライブ自体は不良セクターを検出できず、新しいセクターをスワップインすることはできません。
別のコメントでは、次のように尋ねます:
<ブロック引用>SATA がそれほど信頼できるのであれば、ZFS、btrfs、ReFS などのチェックサム ファイル システムがあるのはなぜですか?
一般的に言えば、データを長期間保存するためにスワップを要求しているわけではありません。スワップ ストレージの制限はシステムの稼働時間であり、システムの仮想メモリ システムを通過するほとんどのデータは寿命の短いプロセスに属しているため、スワップ内のほとんどのデータはそれほど長く持続しません。
その上、カーネルと libc の頻度が増加したため、アップタイムは一般的に年々短くなっています。 更新、仮想化、クラウド アーキテクチャなど
さらに、スワップ内のほとんどのデータは、適切に管理されたシステムでは本質的に使用されておらず、メイン RAM が不足することはありません。このようなシステムでは、最終的にスワップになるのは、プログラムが頻繁に使用しないページだけです。これは、想像以上に一般的です。プログラムがリンクするほとんどの動的ライブラリには、プログラムが使用しないルーチンが含まれていますが、動的リンカーによって RAM にロードする必要がありました。 OS は、ライブラリ内のすべてのプログラム テキストを使用していないことを認識すると、それをスワップ アウトして、プログラムのコードとデータのためのスペースを確保します。 使用しています。そのようなスワップアウトされたメモリ ページが破損した場合、誰が知るでしょうか?
これを、システムの現在のアップタイムを超えて持続するだけでなく、ストレージ システムを構成する個々のストレージ デバイスの寿命を超えて持続するように、データが永続的かつ永続的に保存されることを期待する ZFS のようなものとは対照的です。 ZFS などは、スワップによって解決される問題よりも約 2 桁長い時間スケールで問題を解決しています。そのため、ZFS には Linux スワップよりもはるかに高い破損検出要件があります。
ZFS などは、ここで別の重要な点でスワップとは異なります。ファイルシステムを一緒に RAID スワップしません。複数のスワップ デバイスが 1 台のマシンで使用されている場合、それは JBOD スキームであり、RAID-0 以上とは異なります。 (例:macOS の連鎖スワップ ファイル スキーム、Linux の swapon など) スワップ デバイスは RAID のように相互に依存するのではなく、独立しているため、広範なチェックサムは必要ありません。これは、スワップ デバイスを交換する際に、交換デバイスに移動する必要があるデータについて相互に依存する他のスワップ デバイスを調べる必要がないためです。 . ZFS の用語では、他のストレージ デバイス上の冗長コピーからスワップ デバイスを復元しません。
これはすべて、信頼できるスワップ デバイスを使用する必要があることを意味します。私はかつて 20 ドルの外付け USB HDD エンクロージャを使用して、問題のある ZFS プールを救出しましたが、エンクロージャ自体が信頼できず、プロセスに独自のエラーが発生していることに気付きました。 ZFS の強力なチェックサムのおかげで、ここで私は救われました。スワップ ファイルを使用してストレージ メディアを無頓着に扱うことはできません。スワップ デバイスが機能しなくなり、125 MiB の転送ごとに検出不能なエラーが挿入されるという最悪のケースに近づいている場合は、できるだけ早く交換する必要があります。
この質問におけるパラノイアの全体的な感覚は、ビザンチンの将軍問題の例に帰着します。それを読み、コンピューター サイエンスの世界に問題を説明している学術論文の 1982 年の日付を熟考し、2019 年にこの問題に追加する新たな考えがあるかどうかを判断してください。そうでない場合は、おそらく 使用 するだけです ビザンチン将軍問題を熟知している 30 年間の CS 卒業生によって設計された技術です。
これはよく踏まれた地面です。コンピューター サイエンス ジャーナルでまだ徹底的に議論されていないアイデア、反論、または解決策を思いつくことはおそらくできないでしょう。
SATA は確かに完全に信頼できるわけではありませんが、学術界やカーネル開発チームの 1 つに参加しない限り、最先端の技術に実質的に追加できる立場にはありません。 ZFS、btrfs、ReFS... OS ユーザーとして、OS の作成者がこれらの問題を処理してくれることを信頼する必要があります。ビザンチン将軍について。
現在のところ、スワップ ファイルを ZFS または Btrfs の上に置くことは実用的ではありませんが、上記で安心できない場合は、少なくとも xfs または ext4 の上に置くことができます。これは、専用のスワップ パーティションを使用するよりも優れています。
<ブロック引用>
スワップは??? <--- これは私の質問です
スワップはまだ保護されていません Linux で (ただし、UPD を参照してください)。
もちろん、Linux にはスワップ ストレージとして使用できる ZFS がありますが、状況によってはロックアップが発生するため、事実上そのオプションが無効になります。
Btrfs はまだスワップ ファイルを処理できません。彼らはループバックの使用の可能性について言及していますが、パフォーマンスが低いことが指摘されています。 Linux 5 が最終的にそれを備える可能性があるかどうかは不明な兆候があります(?)…
従来のスワップ自体をチェックサムで保護するパッチは主流になりませんでした。
つまり、全体として：いいえ。 Linux にはまだギャップがあります。
更新 :@sourcejedi が指摘しているように、dm-integrity などのツールがあります。バージョン 4.12 以降の Linux カーネルは、一般的なブロック デバイスにチェックサムを提供するために使用できる device-mapper のターゲットを取得しており、スワップ用のデバイスも例外ではありません。ツールは主要なディストリビューションに広く組み込まれておらず、それらのほとんどは udev サブシステムでサポートされていませんが、最終的にはこれが変更されるはずです。冗長プロバイダーと組み合わせると、MD 別名 Linux ソフトウェア RAID の上に置くと、ビットの腐敗を検出するだけでなく、I/O 要求を正常なデータに再ルーティングすることも可能になるはずです。問題と MD がそれを処理する必要があります。
dm-整合性
参照:Documentation/device-mapper/dm-integrity.txt
dm-integrity 通常、ジャーナリング モードで使用されます。スワップの場合、ジャーナリングなしで行うことができます。これにより、パフォーマンスのオーバーヘッドを大幅に削減できます。クリーンでないシャットダウンの後にエラーが発生するのを避けるために、ブートごとに完全性スワップ パーティションを再フォーマットする必要があるかどうかはわかりません。
dm-integrity の最初の発表では 、著者は代わりに「より高いレベルでのデータ整合性保護」を好むと述べています。スワップの場合、チェックサムを RAM に格納する可能性が開かれます。ただし、そのオプションは、現在のスワップ コードに重要な変更を加える必要があり、メモリ使用量を増加させます。 (現在のコードは、個々のページ/セクターではなく、エクステントを使用してスワップを効率的に追跡します)。
DIF/DIX?
DIX サポートは、Linux 2.6.27 (2008) で Oracle によって追加されました。
DIX を使用すると、エンドツーエンドの整合性が得られますか?
ベンダーに相談できます。彼らがそれについて嘘をついているのかどうか、どうやって見分けることができるのか私にはわかりません.
DIX は、OS (オペレーティング システム) と HBA の間で転送中のデータを保護するために必要です。 .
DIF は単独で、HBA とストレージ デバイス間を転送中のデータの保護を強化します。 . (参照:エラー率の違いに関するいくつかの数値を含むプレゼンテーション)。
ガード フィールドのチェックサムが標準化されているからこそ、何も指定せずに DIX コマンドを実装することが技術的に可能です。 保存中のデータの保護。読み取り時に HBA (またはストレージ デバイス) にチェックサムを再生成させるだけです。この見通しは、元の DIX プロジェクトによって非常に明確になりました。
- DIF/DIX は 直交 です 論理ブロックのチェックサムへ
- 私たちはまだあなたを愛しています、btrfs!
- 論理ブロック チェックサム エラーは、破損したデータの検出に使用されます
- 読み取り時に検出
- ... 数か月後、元のバッファが失われる可能性があります
- 元のバッファが文字化けしている場合、冗長なコピーも問題になる可能性があります
- DIF/DIX はプロアクティブな破損の防止に関するものです
- そもそも不良データがディスクに保存されるのを防ぐ
- ...そして元のバッファがメモリから消去される前に問題を発見する
-- oss.oracle.com からの lpc08-data-integrity.pdf
DIX に関する初期の投稿の 1 つで、ドライブが DIF をサポートしていない場合でも、OS と HBA の間で DIX を使用できる可能性について言及しています。
DIX が現在使用されている「エンタープライズ」コンテキストでは、完全な嘘は比較的ありそうにありません。人々はそれに気付くでしょう。また、DIF は、520 バイトのセクターでフォーマットできる既存のハードウェアに基づいていました。 DIF を使用するためのプロトコルでは、最初にドライブを再フォーマットする必要があると言われています。 sg_format 指図。
可能性が高いのは、真のエンド ツー エンドの原則に従わない実装です。一例を挙げると、CPUサイクルを節約するためにDIXの弱いチェックサムオプションをサポートするベンダーが言及されており、スタックのさらに下にあるより強力なチェックサムに置き換えられます。これは便利ですが、完全なエンド ツー エンドの保護ではありません。
または、OS が独自のチェックサムを生成し、アプリケーション タグ スペースに格納することもできます。ただし、現在の Linux (v4.20) ではこれはサポートされていません。 2014年に書かれたコメントは、これは「アプリケーションタグスペースの使用を実際に許可するストレージデバイスはほとんどない」ためである可能性があることを示唆しています. (これがストレージ デバイス自体、HBA、またはその両方を指しているかどうかは定かではありません)。
Linux で動作する DIX デバイスにはどのようなものがありますか?
<ブロック引用>データと整合性メタデータ バッファの分離、およびチェックサムの選択は、Data IntegrityExtensions [DIX] と呼ばれます。これらの拡張機能はプロトコル本体 (T10、T13) の範囲外であるため、Oracle とそのパートナーは Storage Networking Industry Association 内でそれらを標準化しようとしています。
-- v4.20/Documentation/block/data-integrity.txt
ウィキペディアによると、DIF は NVMe 1.2.1 で標準化されています。 SCSI HBA の場合、基準となる標準がない場合、これを特定するのは少し難しいようです。現時点では、「Linux DIX」サポートについて話すのが最も正確かもしれません:-)。利用可能なデバイスがあります:
<ブロック引用>SCSI T10 DIF/DIX [sic] は、Red Hat Enterprise Linux 7.4 で完全にサポートされます。ただし、ハードウェア ベンダーが認定し、特定の HBA およびストレージ アレイ構成に対して完全なサポートを提供する場合に限ります。 DIF/DIX は、他の構成ではサポートされていません。ブート デバイスでの使用はサポートされておらず、仮想化ゲストではサポートされていません。
現時点では、次のベンダーがこのサポートを提供することが知られています...
-- RHEL 7.5 リリースノート、第 16 章ストレージ
RHEL 7.5 リリース ノートに記載されているハードウェアはすべてファイバー チャネルです。
私はこの市場を知りません。 DIX は将来、サーバーでより広く利用できるようになる可能性があるようです。民生用 SATA ディスクで使用できるようになる理由はわかりません。コマンド形式の事実上の標準さえないことがわかっている限りです。 NVMe でより広く利用できるようになるかどうかに興味があります.