☰

希薄な 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の違いによると確信しています。

たとえば、詳しく説明します。スパースファイルは、ディスクに空のブロックが割り当てられていない（つまり、すべてゼロ）ファイルです。 FSのブロックサイズが小さいほど、そのブロックを見つける可能性が高くなります。したがって、問題は、ターゲットのブロックサイズがソースのブロックサイズよりも大きいために発生する可能性があります。

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

また、見ることができますServerFaultに関するこの質問

答え2

私に最適なソリューションは最初に実行することでした。

virt-sparsify imagename

少し時間が必要です。これにより、ls -hおよびにdu -h報告された同じ寸法でより小さいサイズの画像が生成されますdu -h --apparent-size。ただし、画像をマウントすると正しいサイズが報告され、期待どおり大きくなります。

その後、画像を再同期します。

関連情報