私は主にplexとServiio（dlnaサーバー）で使用するLinuxメディアサーバーを持っています。私はt400 4GB GPU（トランスコーディング）、16GB DDR4 RAM、i7-6700 CPUを持っています。今3つのSSDがあります。映画用の1TB、スワップ用の250GB（より小さいSSDは見つかりません）、別の500GBのSSDは使用されません。このSSDをキャッシュとして使ってみようかと思いました。 2つのHDDがUSB経由で外部からPCに接続され、システムにSamba共有が搭載されています（写真とビデオを保存するNASから）。問題は、この500GB SSDを外部HDDおよびSamba共有からの着信データのキャッシュとしてどのように使用するかです。 （また、私のNASの読み取り負荷を減らすために）。
ベストアンサー1
他のPCで同じようにうまく機能する必要がないローカルブロックデバイスに自分自身を制限できる場合（つまり、SMB共有を無視してUSBディスクを使用）、埋め込みデータにアクセスするために他のコンピュータに接続することはもはやありません。簡単な作業ではありません。 ））、LVMキャッシュは賢明な選択になります。man lvmcacheこれはコンテンツの読み取り文書です。bcache似たようなことができ、もう少し古く、それほど良くありませんlvmcache。
ここでの問題は、キャッシュ戦略が以下に基づいていることです。彫刻存在するブロックデバイス、いいえ文書存在するファイルシステム。これは、ネットワークアクセスをキャッシュするのには適していません。
技術的には、overlayfsオーバーレイを介してアクセスするときに子ファイルシステムにアクセスするファイルを「追加」するなどのことを行うことができます（つまり、overlayfsという用語でcopy_up読み取り時、書き込みアクセス時だけでなく）。ただし、アクセスできなくなったサーバーでデフォルトのソースファイルが変更されたかどうかを検出するメカニズムが必要です。硬い！したがって、キャッシュが要求されたデータを理解できるようにネットワークファイルシステムドライバに統合する必要があり、overrideFSは必ずしも必要ではありません。
最も近いのは、ファイルの緩やかな一貫性を可能にする場合（つまり、2人が同時に同じファイルにアクセスしようとし、どちらか一方または両方を変更しようとすることはありません）あるということです。これfsc CIFSマウントオプション、cachefilesdSSDのファイルシステムでキャッシュを実行します。
だから結論：
ローカルUSBディスクの場合は、それをボリュームグループに物理ボリュームとして追加し、SSDを同じグループに別の物理ボリュームとして追加し、
lvmcacheまずSSDに論理ボリュームを作成して、SSDをUSBディスクへのすべてのアクセス用のキャッシュにします。これにより、ボリュームはUSBディスク（2つの物理ディスクにまたがる可能性があります）に常駐する論理ボリュームですが、SSD SSDの論理ボリュームにキャッシュされます。リモートSMBファイルシステムの場合、
fscファイルシステムキャッシュを有効にするには、cachefilesdキャッシュをローカルボリュームに配置するように構成されたデーモンを実行します。 （上記の発表からわかるように、これはSSDに直接あるボリュームでも、HDDでサポートされ、SSDに加速されるキャッシュアクセラレーションボリュームでもあります。）