两个 ext4 挂载,完全 rsynced,文件总数相同,但总字节大小不同。为什么?

两个 ext4 挂载,完全 rsynced,文件总数相同,但总字节大小不同。为什么?

问题

我们在两个磁盘上有两个挂载点,它们都是完全相同的类型。两个磁盘都格式化为 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

提出了要求dudf输出,结果是:

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

因此磁盘1和磁盘2之间仍然有52,872的差异。

答案1

原因有很多。例如,您不使用-a-l,因此符号链接将转换为普通文件。您不使用 ,-H因此硬链接将成为普通文件。

Unix/Linux 上也存在一种现象,即已删除的文件仍会占用空间,直到所有打开该文件的进程决定关闭它。在 rsync 之前,目标上可能还有打开的文件吗?

最后,这可能是由于源sparse files没有被正确处理而引起的问题,但是这种可能性较小,因为 rsync 通常可以很好地处理它们。

PS rsync FAQ 给出了一些其他可能性(来源):

  1. 如果您的目标比源略小,则可能是目录大小不同造成的。这仅仅是由于目录如何分配磁盘空间而造成的,实际上无法解决。我设计了一个快速 shell 命令来添加当前目录中的所有文件大小,但不包含目录大小:
echo `find . -type f -ls | awk '{print $7 "+"}'`0 | bc
  1. 文件系统类型、块大小、文件松弛开销等也存在差异,这会导致结果不同。
tune2fs -l /dev/your_block_device | grep -i 'block size'
  1. 如果您已经检查了所有这些,但仍然对无法解释的大小差异感到困扰,那么我想指出,简单的大小对于数据复制操作的完整性或准确性检查并不是非常有用。它根本不检查文件的内容,并且会受到我上面解释的变化的影响。我建议使用实际的文件验证实用程序,例如CFV使用真实加密哈希来验证文件。cfv 实用程序与简单md5sum实用程序非常相似,只不过它是递归的、速度更快,并且有一个 %completion 栏。

相关内容