☰

スパース QEMU イメージの rsync によりディスク サイズが増加する

tag-icon • tag-icon rsync qemu xfs sparse-files
スパース QEMU イメージの rsync によりディスク サイズが増加する

別のサーバーに転送したいスパースな生の QEMU イメージがあります。次のqemu-img infoようになります:

image: sparse.img
file format: raw
virtual size: 50G
disk size: 16G

次のように転送します:

rsync -azhP --sparse origin:/path/to/img/sparse.img .

現在、宛先サーバーには次のものがあります:

image: sparse.img
file format: raw
virtual size: 50G
disk size: 40G

ただし、virt-sparsifyコピーしたイメージを再度実行すると、次のようになります。

image: sparse.img
file format: raw
virtual size: 50G
disk size: 16G

両方のサーバーは XFS ファイルシステム上で CentOS 7.2 を実行しています。それで何が起こったのでしょうか?

アップデート：

さらに調査してみると、rsyncはスパースファイルをうまく処理できず、別のツールを使う方が良いという投稿がいくつか見つかりました。タールなど、スパース ファイルを転送します。

tar転送後に を実行してrsync --inplace、ファイルがエラーなく転送されたかどうかを確認できます。ここ。

別の解決提案された方法は、転送先に同じサイズの空のスパース ファイルを作成し、それを使用してrsync --inplace実際のデータを転送するというものでした。

rsync --sparseなぜこのように動作するのかを 実際に説明していないため、これを解決策として書きませんでした。

答え1

これは、送信元と送信先の間の FS の不一致によるものだと思います。

例を挙げて詳しく説明しましょう。スパース ファイルとは、ディスク上に空のブロック (つまり、0 でいっぱいのブロック) が割り当てられていないファイルのことです。FS 上のブロック サイズが小さいほど、そのようなブロックが見つかる可能性が高くなります。したがって、問題は、宛先のブロック サイズがソースよりも大きいことが原因である可能性があります。

私が知らない他の XFS パラメータがあるかもしれません。

参照ServerFaultのこの質問

答え2

私が見つけた最も効果的な解決策は、まず

virt-sparsify imagename

少し時間がかかります。これにより、、およびls -hの両方で同じサイズを報告する、より小さいサイズのイメージが生成されます。ただし、イメージをマウントすると、正しいサイズが報告されます (そして、予想どおりに拡大します)。du -hdu -h --apparent-size

次に、そのイメージを rsync します。

関連情報