2つのext4マウント、完全にrsynced、同じ合計ファイル量、異なる合計バイトサイズ。どうして？

問題

2つのディスクに2つのマウントポイントがあり、どちらもまったく同じタイプです。両方のディスクはext4でフォーマットされています。

rsyncソースから宛先に同期するオプションを指定したコマンドが実行されます。

rsyncの実行後、次のデータが表示されます。

ディスク1-ソース

315.8 GiB (339,148,905,125) - 476,038 files, 21,975 sub-folders.

ディスク2-宛先

315.8 GiB (339,098,108,411) - 476,038 files, 21,975 sub-folders.

差

50,796,714 バイト（〜50 Mb）

使用コマンド

rsync -r -t -p -o -g -v --progress --delete --ignore-existing -s /media/user/disk1 /media/user/disk2

質問

合計バイトサイズが異なるのはなぜですか？

更新

提案された答えが試みられました。ソースと宛先の間のバイトサイズは、サイズの均等化の改善を示しませんでした。

推奨される応答コマンドには-a、-lスイッチとスイッチが含まれ、アーカイブとシンボリックリンク転送が追加されました。

rsync -a -r -t -p -o -g -v -l --progress --delete --ignore-existing -s /media/user/disk1 /media/user/disk2

（結果）

ディスク1-ソース

315.8 GiB (339,148,905,125) - 476,038 files, 21,975 sub-folders.

ディスク2-宛先

315.8 GiB (339,098,108,411) - 476,038 files, 21,975 sub-folders.

差

50,796,714 バイト（〜50 Mb）

状態

問題は解決しませんでした。

さらなる研究

SuperUserで見つかった同様の問題：

https://superuser.com/questions/442539/why-do-two-directory-hierarchies-that-are-in-sync-have-different-sizes

ServerFaultから：

Rsyncサイズはソースから宛先への違いです

更新2

要求duとdf出力が行われ、結果は次のとおりです。

root@system:/# du -s /media/user/disk1

332172440 /media/user/disk1

root@system:/# du -s /media/user/disk2/

332119568 /media/user/disk2/

root@system:/# df /media/user/disk1

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sdc 528316088 332243868 169212316 67% /media/user/disk1

root@system:/# df /media/user/disk2/

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sdb 528316088 332190996 169265164 67% /media/user/disk2

したがって、disk1とdisk2の間にはまだ52,872の差があります。

多くの理由で。たとえば、-aまたはを使用しない-lため、シンボリックリンクは通常のファイルに変換されます。使用しない-Hので、ハードリンクは通常のファイルになります。

また、Unix / Linuxには、開かれたすべてのプロセスが閉じることを決定するまで、削除されたファイルがまだスペースを消費するという現象があります。rsyncの前にDestinationで開いているファイルがある可能性がありますか？

最後に、Source sparse filesが適切に処理されないという問題が発生する可能性がありますが、rsyncは通常それらを適切に処理するため、発生する可能性は低くなります。

PS rsync FAQには、他にもいくつかの可能性があります（ソース）：

2. ターゲットがソースよりわずかに小さい場合、考えられる原因はディレクトリサイズの違いです。これは、単にディレクトリがディスクスペースを割り当てる方法が原因であり、実際には役に立たない。ディレクトリサイズを含めずに、現在のディレクトリのすべてのファイルサイズを合計するクイックシェルコマンドを考案しました。

echo `find . -type f -ls | awk '{print $7 "+"}'`0 | bc

5. ファイルシステムのタイプ、ブロックサイズ、ファイルスラックのオーバーヘッドなどにも違いがあるため、結果が異なる場合があります。

tune2fs -l /dev/your_block_device | grep -i 'block size'

6. これをすべてチェックしても、説明できないサイズの違いに悩まされる場合は、単純なサイズは、データコピー操作の完全性や正確性を確認するのにあまり役に立たないことを指摘したいと思います。ファイルの内容はまったくチェックされず、上で説明したバリエーションの影響を受けます。cfvなどの実際のファイル検証ユーティリティを使用して、実際の暗号化ハッシュを使用してファイルを検証することをお勧めします。cfvユーティリティはmd5sum、再帰的で高速であり、％completionバーがあることを除いて、単純なユーティリティに非常に似ています。