linux拷贝文件大小不一样,linux – 使用rsync复制数据会导致大小差异

这种差异很可能是由旧磁盘上人口稀少的文件引起的.

无论如何,让我们首先检查文件和inode编号是否相同：

> issue find< path> |两个挂载点上的wc -l.文件/目录的数量是否相同？

>问题df -i. inode的数量是否相同？

如果两个问题的答案都是肯定的,那么差异可以通过新磁盘上更稀疏的文件来解释.但什么是稀疏文件？简而言之,稀疏文件是普通文件,它们比它们看起来要小.这是可能的,感谢(相对)现代文件系统的一个功能,而不是将所有零写入文件,只需设置一个标志告诉系统“这个文件(或部分)充满了零,不要让我写商场”.

默认情况下,du报告文件占用的实际空间,而不是表观大小.要显示表观尺寸,请使用du –apparent-size(其他选项,请参阅du manpage)

对于实际示例,您可以使用命令truncate test.img -s 1G创建稀疏文件.正如ls所报告的那样,新创建的文件大小为1 GB,但是如果你尝试du -hs test.img,你会看到一个非常非常小的文件大小(甚至可能是零！).怎么可能？如上所述,现代文件系统有时会对应用程序“撒谎”,报告实际上不存在的分配大小.另一方面,du -hs –apparent-size test.img将打印与ls相同的大小.

当您开始写入稀疏文件时,文件系统将动态分配所需的空间.例如,发出dd if = / etc / services of = test.img conv = notrunc,nocreat会将一些数据写入以前全稀疏的test.img文件中.现在,运行du -hs test.img将报告为数据存储分配的~600 KB.

一个显而易见但非常重要的含义是,稀疏文件支持只能针对零填充文件(或部分文件)进行优化.在写入文件的同一时刻,其分配的空间开始增长.如果您将其他零写入文件,这是真实的事件,除非应用程序知道如何处理稀疏文件(在这种情况下,应用程序将建议文件系统它将写入全零,并且文件系统优化符合).

如果你想真正预先分配一些空间怎么办？然后你可以使用fallocate test.img -l 1G.如果你执行ls; du -hs test.img; du -hs –apparent-size test.img,你会发现所有工具都报告了相同的大小,因为该文件确实是由fallocate调用完全分配的.

简而言之,在复制期间,有可能以较少的稀疏方式重新创建一些文件,用“真实”零替换稀疏部分.要在rsync中使用稀疏文件,必须使用-S选项.