私は自分のスクリプトを使用して dm-cache デバイスを作成しています: http://pastebin.com/KTSzL6EA
実際には、次のコマンドが実行されます:
dmsetup create suse-cache-metadata --table 0 15872 linear /dev/mapper/suse-cache 0
dmsetup create suse-cache-blocks --table 0 125813248 linear /dev/mapper/suse-cache 15872
dmsetup create storagecached --table 0 2930266112 cache /dev/mapper/suse-cache-metadata /dev/mapper/suse-cache-blocks /dev/mapper/storage 512 1 writethrough default 0
dmsetup resume storagecached
1.5TB USB 2.0 HDD をキャッシュするための 60GB SSD LVM ボリューム。キャッシュされた dm デバイスを次のようにマウントしています:
mount -t btrfs -o noatime,autodefrag,compress=lzo,space_cache /dev/mapper/storagecached /mnt/storage
しかし、まったく機能していないようです。キャッシュされたデバイス上のコンテンツにアクセスするたび、また、何らかのボットが私の Web サイトにアクセスするたびに、外付け HDD がスピンアップしていることに気づきました。おそらく、キャッシュされているはずなのに、外付け HDD が連続的なスピンアップとスピンダウンを処理できないため、約 1 週間後には I/O エラーが発生します。
実際にベンチマークをいくつか実行してみることにしましたが、ddコマンドを使用して 8 GB のファイルを /dev/null にコピーすると、わずか 40 MB/秒しか達成されませんでした。これは、キャッシュされていない HDD と同じ速度です。常に。キャッシュを消去したドライ ランと、キャッシュする必要があると思われる 3 番目または 4 番目の読み取りの両方で。キャッシュに使用されている SSD は、ルート パーティションで 92 MB/秒を達成しています。もちろん、すべてのベンチマークの後、RAM キャッシュのパフォーマンスへの影響を排除するために Linux RAM キャッシュを消去していました。
私は実際にこのスクリプトを 2 台の PC で使用していますが、どちらも動作していないようです。writethrough では書き込み速度が上がらないことはわかっていますが、読み取りの方が心配です。
編集：
ログを調べたところ、dmsetup statusキャッシュ ヒット率が非常に低いことに気付きました。これは btrfs のせいでしょうか?
答え1
dm キャッシュは、ブロックをキャッシュ デバイスに昇格するのに時間がかかります。Linux RAM キャッシュとは異なり、デフォルトの dmcache ポリシーでは、特定のデータを SSD に昇格させるために、少なくとも数回の読み取りが必要です。通常は、10 回を超える大量の読み取りが必要です。マシンの予備 RAM の量が比較的多い場合、dmcache を「トレーニング」するのに長い時間がかかることがあります。キャッシュ サイズが予備 RAM の量と似ていて、頻繁に使用されるデータが大量のスペースを占有する場合、dmcache は正常に動作しない可能性があります。
答え2
セットアップには lvmcache(7) を使用すると、より満足できるでしょう。また、man ページは起動と実行に非常に役立ちます。writeback/writethrough ポリシーと smq キャッシュ ポリシーに注意してください。これらは、新しいリリース (カーネル 4.2 以降) でのみデフォルトで有効になっています。また、これは RHEL 7.2 以降でもデフォルトで有効になっています。
私の講演は以下からご覧いただけます:https://www.youtube.com/watch?v=6W_xK5Ks-Lw またはスライドを読んでください:https://www.linuxdays.cz/2017/video/Adam_Kalisz-SSD_cache_testing.pdf