私はZFSを実験し、ついにそれがやけどをするのに十分な成熟したことを認めました。
マイグレーションのために、現在LVM JBOD設定であるホームNASボックスがいっぱいですが、1つのドライブに割り当てられていないスペースがかなりあります。
私はスパースファイルで生成されたzpoolを使ってzfsを試してきました。ファイルベースの仮想デバイスを物理パーティションに置き換えることは、非常に柔軟なアプローチのように見えます。
このアイデアを極端に適用して、すでに非常にいっぱいになっているこのファイルシステムで、既存のハードウェアと同じサイズの希少ファイルvdevを作成し、コンテンツをLVMからZFSアレイに移動するとどうなりますか？
理論的には、LVMファイルシステムに増加するZFSを収容するのに十分な空き容量がある限り、ファイルが削除されても機能し続ける必要があります。これにより、LVMファイルシステムは実際のZFSイメージを除いて最終的に空になり、物理パーティションに置き換えることができます。
断片化は、少なくとも性能に重大な影響を及ぼすと予想される。
表面的に、これは完全に狂った音のように聞こえます。同じファイルシステムの別のコンテナにファイルをコピーしたいのはなぜですか？したがって、私はこのデータセットが重複排除と圧縮を切り替えることで利点を得ることができると思うので、より多くの空き容量を確保できます。ただし、主な目的は、「ドライブ」をアップグレードできるZFSプールにデータを保存できる柔軟性を得ることです。つまり、物理ハードウェアと交換することです。
このクレイジーな質問は以下からインスピレーションを得ました。このブログ投稿ループバックデバイスを一時ハードディスク交換用に使用して、アレイのRAIDレベルを変換します。
ベストアンサー1
既存のファイルシステムにzpoolをファイルとして配置することは、そのファイルシステムに依存して一貫性を提供し（危険に見える）、ZFSがキャッシュを最大限に活用できないことを意味します。私はZFSがファイルから物理デバイスへの転送をどれだけうまく処理するのかわかりません。おそらく実際の苦情はありませんが、vdevをより小さなデバイスとして気に入らないような問題に直面する可能性があります。 （私が読んだところによると、多くの人がこの設定のために苦しんでいるので、そのプロパティautoexpand=onに注意したいかもしれません。そのテーブルの弟autoreplace）。あるいは、LVM 上で ZFS を実行することもできます。これは可能かもしれませんが、ZFSは大容量デバイスのみを表示できるため、デバイスをインテリジェントに処理することはできません。 ZFSは単純なファイルシステムではなくボリュームマネージャでもあるため、正しく交換してください。両方一般的なファイルシステムとLVM。複数のディスクにメタデータを配置し、冗長性のためにzpool内に複数のデータコピーを配置することを含む多くのZFS機能は、物理ストレージのレイアウトを理解するのに最適です。
私もZFSへの移行について考えていました。私が考えることができる最良の選択移行にはハードドライブがもう1つ必要です。現在アレイにある最小の物理ドライブと最小サイズの異なる別のハードドライブをインストールし、そこにZFSプールとファイルシステムを作成し（JBODで構成されていますが、デバイスは1つだけ）、できるだけ多くのデータを移動します。できるだけこのハードドライブに移動できます。 （LVMを実行していないので、minドライブのすべてのエントリをZFS fsに移動します。）1つの物理ディスクを削除してLVMアレイを減らし、ZFS zpoolを利用可能なディスクに展開してからいくつかのファイルを移動します。 、すすぎ、完了するまで繰り返します。シンボリックリンクを賢く使用したりエクスポートをうまく処理したりすることで、NASボックス内のファイルを同時に使用するすべての人にプロセスを透過的にすることもできます。