dm キャッシュ

dm-cache は、 Linux カーネルのデバイス マッパーのコンポーネント (より正確にはターゲット) です。デバイス マッパーは、ブロック デバイスを高レベルの仮想ブロック デバイスにマッピングするためのフレームワークです。これにより、フラッシュベースのソリッド ステート ドライブ(SSD)などの 1 つ以上の高速ストレージ デバイスが、ハード ディスク ドライブ(HDD)などの 1 つ以上の低速ストレージ デバイスのキャッシュとして機能するようになります。これにより、ハイブリッド ボリュームが効果的に作成され、セカンダリ ストレージのパフォーマンスが向上します。

dm-cache の設計では、単一のハイブリッド ボリュームを作成するために 3 つの物理ストレージ デバイスが必要です。dm-cache は、これらのストレージ デバイスを使用して、実際のデータ、キャッシュ データ、および必要なメタデータを個別に保存します。構成可能な動作モードとキャッシュ ポリシー (後者は個別のモジュールの形式) によって、データ キャッシュが実際に実行される方法が決まります。

dm-cache はGNU General Public License (GPL)の条件に基づいてライセンスされており、主な開発者は Joe Thornber、Heinz Mauelshagen、Mike Snitzer です。

dm-cacheは、ハードディスクドライブ（ HDD ）にアクセスする際に、追加の間接レベルとしてソリッドステートドライブ（SSD ）を使用し、回転磁気媒体に基づく低速の機械式HDDのキャッシュとして高速なフラッシュベースのSSDを使用することで、全体的なパフォーマンスを向上させます。その結果、SSDの高価な速度と、低速だが安価なHDDが提供するストレージ容量が組み合わされます。^{[1]さらに、}クラウド環境で仮想マシンの共有ストレージシステムとして使用されるストレージエリアネットワーク（SAN） の場合、dm-cacheはクライアント側のローカルストレージを使用してデータキャッシュを提供することで、全体的なパフォーマンスを向上させ、SANの負荷を軽減することもできます。^{[2] [3] [4]}

dm-cache は、Linux カーネルのデバイス マッパーのコンポーネントとして実装されています。デバイス マッパーは、物理ブロック デバイスと仮想ブロック デバイス間でさまざまなマッピングを作成できるボリューム管理フレームワークです。デバイス間のマッピングの作成方法によって、仮想ブロックが基になる物理ブロックに変換される方法が決まり、特定の変換タイプはターゲットと呼ばれます。^[5] マッピング ターゲットとして機能する dm-cache により、作成された仮想ブロック デバイスに SSD ベースのキャッシュを組み込むことができます。一方、構成可能な動作モードとキャッシュ ポリシーによって、dm-cache が内部的にどのように動作するかが決まります。動作モードによって、HDD と SSD の間でデータを同期させる方法が選択され、各ポリシーを実装する個別のモジュールから選択可能なキャッシュ ポリシーによって、どのブロックを昇格 (HDD から SSD に移動)、降格 (SSD から HDD に移動)、クリーンアップするかなどを決定するアルゴリズムが提供されます。 ^[6]

マルチキュー(mq) または確率的マルチキュー(smq) キャッシュ ポリシーを使用するように構成すると(後者がデフォルト)、dm-cache は実行されたランダム読み取りと書き込みに関連するデータを SSD に保存し、 SSD のほぼゼロのシーク時間を活用し、HDD のパフォーマンスのボトルネックとなる一般的なI/O操作を回避します。シーケンシャル読み取りと書き込みに関連するデータはSSD にキャッシュされないため、そのような操作中に望ましくないキャッシュの無効化を回避できます。シーケンシャル I/O 操作は機械的性質上 HDD に適しているため、パフォーマンスの点ではこれは有益です。シーケンシャル I/O をキャッシュしないことは、キャッシュとして使用されるSSD の寿命を延ばすのにも役立ちます。^[7]

同様の目標を持つ別のdm-cacheプロジェクトは、 IBMでのインターンシップの成果として、Eric Van HensbergenとMing Zhaoによって2006年に発表されました。^[8]

その後、ジョー・ソーンバー、ハインツ・マウエルシャゲン、マイク・スニッツァーが独自の実装を提供し、その結果、dm-cacheがLinuxカーネルに組み込まれました。dm-cacheは、2013年4月28日にリリースされたカーネルバージョン3.9でLinuxカーネルメインラインに統合されました。 ^{[6] [9]}

dm-cacheでは、ハイブリッドボリュームとして機能するマップされた仮想ブロックデバイスを作成するには、3つの物理ストレージデバイスが必要です。^[6]

• 元のデバイス – 低速のプライマリストレージ（通常はHDD）を提供します
• キャッシュデバイス – 高速キャッシュを提供します（通常は SSD）
• メタデータデバイス – ブロックの配置とそのダーティフラグ、およびブロックごとのヒット数など、キャッシュポリシーに必要なその他の内部データを記録します。メタデータデバイスは複数のキャッシュデバイス間で共有することはできず、ミラーリングすることをお勧めします。

内部的には、dm-cache は固定サイズのブロックを介して各オリジンデバイスを参照します。これらのブロックのサイズはキャッシュエクステントのサイズに等しく、ハイブリッドボリュームの作成時にのみ構成可能です。キャッシュエクステントのサイズは 32  KBから 1  GBの範囲で、32 KB の倍数である必要があります。通常、キャッシュエクステントのサイズは 256 KB から 1024 KB です。ディスクセクターよりも大きいキャッシュエクステントを選択すると、メタデータのサイズとキャッシュスペースの無駄遣いの可能性との間の妥協点となります。キャッシュエクステントが小さすぎると、メタデータデバイスとカーネルメモリの両方でメタデータのサイズが増加します。一方、キャッシュエクステントが大きすぎると、ヒット率が高い場合でもエクステント全体をキャッシュするため、無駄なキャッシュスペースの量が増えます。^{[6] [10]}

dm-cache がサポートする動作モードは、デフォルトのwrite-back 、 write-through、およびpass-throughです。 write-back 動作モードでは、キャッシュされたブロックへの書き込みはキャッシュデバイスにのみ行われ、元のデバイスのブロックはメタデータでダーティとしてマークされるだけです。 write-through 動作モードでは、データが元のデバイスとキャッシュデバイスの両方に到達し、クリーンなブロックがダーティとしてマークされるまで、書き込み要求は完了として返されません。 pass-through 動作モードでは、すべての読み取りはキャッシュを回避して元のデバイスから直接実行され、すべての書き込みは元のデバイスに直接行われます。キャッシュ書き込みヒットは、キャッシュされたブロックの無効化も引き起こします。 pass-through モードでは、キャッシュデバイスの状態が元のデバイスと一致しているかどうかわからない場合に、ハイブリッドボリュームをアクティブ化できます。^{[6] [11]}

dm-cache が両方向に実行するデータ移行の速度 (つまり、データの昇格と降格) は、設定された速度まで抑制できるため、元のデバイスとキャッシュ デバイスへの通常の I/O を維持できます。ハイブリッド ボリュームを廃止したり、キャッシュ デバイスを縮小したりするには、クリーナー ポリシーを使用する必要があります。クリーナーポリシーは、メタデータでダーティとしてマークされているすべてのブロックをキャッシュ デバイスから元のデバイスに効果的にフラッシュします。^{[6] [7]}

2015年8月現在^[update]、Linuxカーネルバージョン4.2では、^[12]次の3つのキャッシュポリシーがLinuxカーネルメインラインで配布されており、そのうちdm-cacheはデフォルトで確率的マルチキューポリシーを使用しています。^{[6] [7]}

マルチキュー (mq)

マルチキュー(mq) ポリシーには、16 個のキューが 3 セットあります。最初のセットはキャッシュを待機しているエントリに使用され、残りの 2 セットはすでにキャッシュ内にあるエントリに使用されます。後者のセットは分離されているため、クリーン エントリとダーティ エントリは 2 つのセットのそれぞれに属します。キュー内のキャッシュ エントリの経過時間は、関連する論理時間に基づきます。キャッシュに入るエントリ (つまり、昇格するエントリ) の選択は、可変しきい値に基づき、キューの選択はエントリのヒット数に基づきます。このポリシーは、さまざまなキャッシュ ミスコストを考慮し、さまざまな負荷パターンに合わせて自動的に調整することを目的としています。

このポリシーは、ランダム I/O 操作とシーケンシャル I/O 操作を区別するための異なる構成可能なしきい値を使用して、シーケンシャル I/O 操作をキャッシュ経由でルーティングできるように内部的に追跡します。その結果、大規模な連続 I/O 操作は元のデバイスによって実行されるようになります。これは、このようなデータ アクセス パターンが HDD に適しており、望ましくないキャッシュの無効化を回避するためです。

確率的マルチキュー (smq)

確率的マルチキュー( smq) ポリシーは、マルチキューポリシーと同様に動作しますが、動作に必要なリソースが少なく、特に、キャッシュされたブロックを追跡するために使用するメイン メモリの量が大幅に少なくなります。また、マルチキューポリシーのヒット カウントを「ホットスポット」キューに置き換え、データの昇格と降格をLRU (最近最も使用されていないデータ) ベースで決定します。その結果、このポリシーは、マルチキューポリシーと比較してパフォーマンスが向上し、さまざまな負荷パターンに自動的に適応し、さまざまなしきい値の設定が不要になります。

クリーナー

クリーナーポリシーは、メタデータでダーティとしてマークされているすべてのブロックを元のデバイスに書き戻します。この操作が完了したら、ハイブリッド ボリュームを廃止するか、キャッシュ デバイスのサイズを縮小することができます。

論理ボリュームマネージャには、 LVMと統合されたlvmcacheラッパーを提供するが含まれています。 ^[13]dm-cache

• bcache  – Linuxカーネルのブロック層キャッシュ。Kent Overstreetが開発。
• Flashcache  – Linuxカーネルのディスクキャッシュコンポーネント。当初はFacebookによって開発された。
• ハイブリッドドライブ - フラッシュベースと回転磁気メディアストレージ技術を組み合わせたストレージデバイス
• ReadyBoost  – Windows Vista以降のMicrosoftオペレーティング システムのディスク キャッシュ ソフトウェア コンポーネント
• スマートレスポンステクノロジー（SRT） – Intelが自社のチップセット用に開発した独自のディスクストレージキャッシュメカニズム
• ZFS  – 同様の統合キャッシュデバイスサポート（L2ARC）を備えたクロスOSストレージ管理システム

• 安定したアップストリームカーネルにおける Linux ブロック キャッシュの選択肢 (PDF)、Dell、2013 年 12 月
• EnhanceIO、bcache、dm-cache のパフォーマンス比較、LKML、2013 年 6 月 11 日
• EnhanceIO、Bcache、DM-Cache のベンチマーク、Phoronix、2013 年 6 月 11 日、Michael Larabel 著
• dm-cache を使用した SSD キャッシュ チュートリアル、2014 年 7 月、Kyle Manna 著
• Re: [dm-devel] [PATCH 8/8] [dm-cache] キャッシュ ターゲット、2012 年 12 月 14 日 (メタデータ デバイスのサイズ設定のガイドライン)