![rsync と du[duplicate] 使用後のディレクトリサイズは異なります。](https://linux33.com/image/199191/rsync%20%E3%81%A8%20du%5Bduplicate%5D%20%E4%BD%BF%E7%94%A8%E5%BE%8C%E3%81%AE%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AF%E7%95%B0%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82.png)
あるSynology NASボリューム(ext4)から別のボリューム(btrfs)にいくつかの特別なディレクトリ(通常の移行ツールではサポートされていません)を移行しました。同期がうまくいったことを確認してみると、サイズが大きく差があることがわかりました。
ブロックサイズの違いがあることはわかっていますが、du
同じボリュームで誤ったデータサイズを提供しています。
ディレクトリ全体の合計サイズが1TBを超えるため、次のコマンドをより小さいサブディレクトリに縮小しました。
その他のサイズ:
sudo du -sm /volume[12]/@synologydrive/@sync/repo/1/2
11418 /volume1/@synologydrive/@sync/repo/1/2
11122 /volume2/@synologydrive/@sync/repo/1/2
ただし、すべてのサブディレクトリに対して正しいサイズ(バイトを使用する場合は多少)を取得します。n
サブディレクトリを選択してください。
sudo du -sm /volume[12]/@synologydrive/@sync/repo/1/2/n
295 /volume1/@synologydrive/@sync/repo/1/2/n
295 /volume2/@synologydrive/@sync/repo/1/2/n
sudo du -sb /volume[12]/@synologydrive/@sync/repo/1/2/n
308387853 /volume1/@synologydrive/@sync/repo/1/2/n
308391693 /volume2/@synologydrive/@sync/repo/1/2/n
*
しかし、以下を使用すると、全く異なるサイズが得られます。 (例:上記の同じボリューム比較コマンドとボリューム2のこのコマンドでも):
sudo du -sm /volume[12]/@synologydrive/@sync/repo/1/2/* | grep n$
295 /volume1/@synologydrive/@sync/repo/1/2/n
200 /volume2/@synologydrive/@sync/repo/1/2/n
sudo du -sb /volume[12]/@synologydrive/@sync/repo/1/2/* | grep n$
308387853 /volume1/@synologydrive/@sync/repo/1/2/n
209533219 /volume2/@synologydrive/@sync/repo/1/2/n
また、ディレクトリの下のすべてのファイルサイズを計算してn
同じサイズを得ました。
ls -lA /volume1/@synologydrive/@sync/repo/1/2/n | tr -s ' ' | cut -f5 -d" " | awk '{s+=$1} END {print s}'
308387597
ls -lA /volume2/@synologydrive/@sync/repo/1/2/n | tr -s ' ' | cut -f5 -d" " | awk '{s+=$1} END {print s}'
308387597
したがって、ディレクトリは正しく「同期」されているように見え(同じファイル数、同じサイズ)、2つの異なるファイルシステム間の違いを解決しようとします。ただし、du
新しいロール1でははるかに大きな寸法が得られます(より正確には、従来のロール2でははるかに小さい)。
これについての説明はありますか?
メモ:
volume1
新しいbtrfsターゲットボリューム(データをコピーした場所)。volume2
以前のext4ソースボリューム(データをコピーしたボリューム)。- データ複製の用途
sudo rsync -a --progress --delete /volume2/@synologydrive /volume1
答え1
OPの下のコメントの@themのおかげで、根本的な原因を見つけました。ソースソースボリュームには、ハードリンクされた複数のディレクトリ/ファイルが含まれており、これらのディレクトリ/ファイルはすべて新しい独立(固定)ディレクトリ/ファイルとして新しいボリュームにコピーされます。
実際、この質問を理解するのに役立つ2つのことがあります。
rsync
ハードリンクはデフォルトで尊重されません。教訓を得る:rsync
switchで実行すると、小さなファイルを効率的に処理するためにswitchを--hard-links
使用することもできます--sparse
。du
デフォルトでは、ハードリンクされたファイルのサイズは含まれません。教訓を得る:スイッチを実行して、du -l
以下を含むすべてのファイルのサイズを計算します。しっかりした接続を持つ人々。表示された寸法に似ていますls
。
これらの2つの側面を理解していないと、ファイルが正しく同期されているかどうかはわかりません。