容量を組み合わせながら、高速ストレージと低速ストレージ全体にわたって多層ファイルシステムを構成する方法は?

容量を組み合わせながら、高速ストレージと低速ストレージ全体にわたって多層ファイルシステムを構成する方法は?

低速500GB磁気HDDと高速500GB SSDを同時に使用する方法を探しています。

容量面で2つを合わせた合理的な割合で終わりたいのですが(800GB以上であればいいです)どのファイルをどのディスクに保存するかを決定するのは難しく、ディレクトリの境界を越えることはほとんど不可能です。

多段階収納形態でも同様のことを考慮したものと見られる。しかし、これまで私が見つけた唯一のメカニズムは、高速ボリュームを遅いボリュームのキャッシュとして使用することです。 500GB HDDのスロードライブで500GB SSDキャッシュで終わるので、これは私にはうまくいきません。単に遅いHDDに入れてSSDを使うよりも良いことはありません。

2つのボリュームにまたがって1つのボリュームから別のボリュームに動的に複製するシステムを考えてみましょう。これはキャッシュと似ていますが、ボリュームを完全に一貫して維持する必要はなく、単一ボリュームよりも多くの容量を提供できます。

これまでに検索した内容はすべて空です。キャッシュをサポートするLVMとXFSへの複数の参照が見つかりました。しかし、両方のデバイスよりも高い容量を達成できることは明らかではありません。

したがって、これが可能であると仮定しましたが、実装方法が見つかりませんでした。


この問題のトリッキーな部分は、1つの最終ファイルシステムのみを使用してソリューションを実装することです。私にとっては、ディレクトリごとに配置するファイルを手動で選択することはできません。

答え1

以下の回答は個人的な経験に基づくものではないので、実際に効果があるかどうかは確かに言うことはできませんが、試してみることができるアイデアだけです。

LVMキャッシュ

キャッシュ論理ボリュームタイプは、小型で高速なLVを使用して、大型で低速なLVのパフォーマンスを向上させます。頻繁に使用されるブロックをより高速なLVに保存してこれを行います。

私が正しく理解した場合は、高速ディスクのキャッシュサイズを制限してから、遅いディスクと残りの高速ディスクの別の論理ボリュームを作成できます。

ブロックキャッシュ

もう一つの可能​​な解決策は隠れ家:

Bcache(ブロックキャッシュ)を使用すると、SSDを他のブロックデバイス(通常は回転するHDDまたはアレイ)の読み取り/書き込みキャッシュ(後書きモード)または読み取りキャッシュ(連続書き込みまたは後書き)として使用できます。

サポートデバイスとキャッシュデバイスの両方が可能です。「フルデバイス、パーティション、またはその他の標準ブロックデバイス。」

理論的には、SSDを200 + 300 GBの2つのパーティションに分割できます。 200GBがキャッシュデバイスとして使用されます。

その後、SSDの残りの300 GBパーティションと遅いディスクを1つの800 GB論理ボリュームにまとめることができます(LVMまたは使用)。ソフトウェアRAID)キャッシュデバイスを使用してキャッシュします。

繰り返しますが、私はこれらのどれも試したことがありません。lvmcacheあなたの目的に適しているようです。両方を試してパフォーマンスを比較することで、どのソリューションが優れているかを判断できます。

答え2

XFSはライブパーティショニングを提供します:

XFSファイルシステムは、通常のディスクパーティションまたは論理ボリュームに常駐できます。 XFSファイルシステムは、データ部分、ログ部分、リアルタイム部分の最大3つの部分で構成されています。 ...

...

リアルタイム部分は、リアルタイムファイルのデータを保存するために使用されます。このファイルの属性ビットは次のように渡されます。xfsctl(3)ファイルが作成された後、ファイルにデータが書き込まれる前です。リアルタイム部分は、複数の固定サイズ範囲(mkfs.xfs(8)時間で指定)に分けられます。ライブセクション内の各ファイルの拡張サイズは、ライブセクション拡張サイズの倍数です。

しかし、制限事項があるので参考にしてください。データはライブパーティションまたは「一般」パーティションに書き込まれるため、パーティションに見られるように容量を拡張するためにデータは前後に移動しません。階層型ストレージシステム

第二に、申請書を作成するには、次のものが必要です。XFS_XFLAG_REALTIMEリアルタイムビット設定ファイルが作成された後にデータが書き込まれる前にライブパーティションを書き込むファイルの場合。

答え3

おおよそのアイデアです。読み取り専用部分がHDDであり(おそらく変更されていないかほとんど変更されないファイルの場合)、上書きがSSD上のFS上書きを検討しましたか?ファイルが安定していると判断した場合は、オーバーレイからHDDにファイルを移動し、オーバーレイにアクティブな作業コピーがある場合は、HDDからファイルを削除するオフラインメカニズムが必要です。このオフラインメカニズムは、SSDがいっぱいになったときに実行できます。明らかに、人々は以前もこの方向を見ていました。Linuxオーバーレイ(OverlayFS)マウントの親ファイルシステムへの変更を子ファイルシステムにマージする

多くのことを行うと、FUSEファイルシステムを作成してオンラインで自動的に実行することも可能です。実際にこの問題を解決する方法があるかもしれません。https://en.wikipedia.org/wiki/Filesystem_in_Userspaceいくつかのアイデアとアドバイス。

答え4

見てファイルシステムのマージ: "mergerfsは論理的に複数のパスをマージします。これをセットの組み合わせと見なしてください。mergefsを介して実行またはレンダリングされるファイルまたはディレクトリは、特定のタスクに対して選択されたポリシーに基づいています。"

そして左心室: 「LVM ボリュームを監視し、使用量に応じてブロックを高速または低速のストレージに移動するアプリケーションです。つまり、Linux で LVM を活用する階層型ストレージマネージャです。」

関連情報