HDDキャッシュとしてのLinux SSD
LinuxサーバーシステムがSSDとユーザーデータ用のHDDにインストールされています。 SSDに空き容量があるので、HDDのリードキャッシュとして使いたい。
可能性を見て、私は見つけました：
dm-cache： https://www.redhat.com/en/blog/improving-read-performance-dm-cache によると、キャッシュがパフォーマンスの向上を示す前に多くの読み取りが必要です。私のユースケースでは、これは良い戦略ではないと思います。
lvmcache：dm-cacheをベースにしており、SSDとHDDを1つのLVに配置する必要があります。キャッシュを透過的にしたいので、最初にLVMマジックを実行しなくても、HDDを別のシステムに簡単に追加できます。
Bcache：HDDをBcache用にフォーマットする必要があります。私が欲しいものではありません。
フラッシュキャッシュ： https://github.com/facebookarchive/flashcache によると、私は欲しいもののように聞こえます（スイッチをオンにするだけです）。
EnhanceIO：Flashcacheに基づいて構築されていますが、2015年以来機能していません。
FlashcacheやEnhanceIOに似ていますが、まだ積極的に維持されていますか？
EnhanceIOはまだコミュニティによって維持されています。最近のカーネルにパッチが適用された lanconnectedによるフォーク と、ほぼ同時期（2019年4月）に最後のコミットが行われた他のいくつかのフォークがあります。私はこれをArchのbtrfsで使用しています dkmsを介して を数年間使用しており、大きな問題に気づいていません。
これは、Linuxカーネルブロックキャッシュの適切な調査です。これらのうち、私はlvmcacheとbcacheのみを検討します。カーネルに統合され、安定したディストリビューションによって文書化されています。
どちらもメタデータのフォーマットが必要ですが、これは簡単に回避できません。
ターゲットシステムもキャッシュをサポートしている場合、ディスクを別のシステムに移動するのは比較的簡単です。 LVM対応のディストリビューションは、簡単なコマンドで自動的に行われない場合でも、ボリュームをスキャンします。 bcacheについても同様です。
どちらの方法でも、ボリュームをファイルシステムのUUIDまたはラベルでマウントし、デバイスの番号付けから抽象化します。
計画的シナリオと計画外のシナリオでキャッシュを削除するためのテスト手順。デタッチパススルーモードのbcacheなど。キャッシュなしでバッキングディスクのみをリカバリできるようになると、キャッシュ前の未処理ディスクに戻す必要がなくなります。
パーティションのサイズを変更してシステムを作成するか、USB HDDを使用して一時的にそこに展開することをお勧めしますか？