与新的硬盘(736G)相比,旧机器的硬盘略小(720G),所以我创建了一个稍大的分区.
所以,我然后运行rsync将所有数据复制到新分区,如下所示：
linux-70e2:/ # time rsync -azprvl /mnt/external-disk/foo /media/sda4/ ... sent 169,237,139,987 bytes received 24,529 bytes 24,419,185.41 bytes/sec total size is 190,542,953,489 speedup is 1.13 real 115m30.297s user 112m13.068s sys 3m59.996s
数据被复制而没有错误.
但是,当我这样做时：
du -h -m -s /mnt/external-disk/foo /media/sda4/foo
我明白了：
162414 /mnt/external-disk/foo 181721 /media/sda4/foo
有人可以解释这个巨大的差异吗？为什么我没有得到相同的结果？这让我疯了好几天了.还有一些其他分区,我也有类似的差异.
两个分区都是ext4.
linux-70e2:/ # mount | grep sda4 /dev/nvme0n1p5 on /media/sda4 type ext4 (rw,relatime,data=ordered) /dev/sda4 on /mnt/external-disk type ext4 (rw,nosuid,nodev,data=ordered,uhelper=udisks2)
据我所知,两个驱动器都是SSD-s没有问题.其中一个是全新的.我在他们两个上运行e2fsck.
另外,我跑了：
find -L /mnt/external-disk type/foo -type l
这不会列出源目录下的任何符号链接.
这不是我第一次使用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选项.
