复制到新服务器的文件系统大 60% - 为什么

Question

复制到新服务器的文件系统大 60% - 为什么

我正在将服务器从 Ubuntu Server 18.02 实例（“saturn”）迁移到新建的 Debian Buster 10 系统（“enceladus”）。我已经通过网络复制了一个完整的文件系统

sudo rsync --progress -au --delete --rsync-path="sudo rsync" /u/ henry@enceladus:/u

Run Code Online (Sandbox Code Playgroud)

我检查了发送方和接收方的目录数和文件数：计数相同。我有一个 RYO Perl 程序，它遍历文件树并将一个树中的每个文件与另一棵树中的对应文件进行比较：它在 52,190 个文件中没有发现差异。两个文件系统都是 EXT4；两者都有 512 字节的逻辑块，4096 个物理块。

然而接收文件系统是 103,226,592,508 字节，而发送文件系统只有 62,681,486,428 字节。如果接收到的文件系统是一个有点小，我可以理解，因为未回收的块; 但是反过来，差别是原来的三分之二！

怎么会这样？我应该担心它，作为某些故障的证据吗？

Answer 1

mat*_*tdm 80

我能想到两件事：

你没用 -H，所以硬链接丢失了。
您没有使用-S，因此稀疏文件可能已被扩展

...这给了预期的结果，在几个 K 之内。非常感谢。 (37认同)
感谢您提供非常有用的建议。没有稀疏的文件，但有大量的硬链接，在它们的末尾有大图片。我正在使用 -H 重新复制（从头开始）并将发布结果。 (14认同)
@mattdm `-a` 标志省略了 `-H`（硬链接），因为处理它需要在内存中保存整个链接文件树，以便可以识别匹配的 inode。它省略了“-H”和“-S”，因为并非所有文件系统都支持这些功能 (13认同)
哦，我知道_为什么_它不包括它们。正如这里所证明的那样，这只是一种陷阱。 (12认同)
是的，`-a` 不包含这些选项，这有点令人惊讶（在 UI 意义上）。 (7认同)
对于未来的读者，如果制作新的 FS 和重做副本不方便，您可以使用 `find -type f -exec fallocate -d {} \;`（`+` 不起作用，fallocate 只适用一次在一个文件上，所以如果你的小文件不稀疏，可以使用`-size +1M`或其他东西来按文件大小过滤）。由于碎片，这比新副本更糟糕：空闲空间分散在使用过的块之间。此外，它会使所有内容变得稀疏，当您可能更愿意拥有一些具有未写入范围（预分配空间）的文件时。 (5认同)
作为进一步的参考，在其他一些文件系统（例如，ZFS、BTRFS 或 XFS）中，这也可能是由于文件中的共享区未被复制为共享而发生的。解决方案是使用 `cp --reflink=always` 强制将共享范围复制为共享，或者使用类似 `duperemove` 之类的工具对数据进行传递以重新删除重复数据。 (5认同)
您可以使用诸如“fslint”或其他重复文件查找器之类的工具来识别重复项并将其硬链接到彼此。（但是，如果某些重复项集*不* 是硬链接，则您必须手动决定是否进行硬链接。或者在像 btrfs 这样的 CoW 文件系统上，使引用链接透明地为重复块节省空间，而无需任何传统的链接语义因此未来的更改仅适用于更改后的文件。） (4认同)
此外，一些文件系统支持压缩（例如 btrfs 支持 gzip、lzop 和 zstd）。在某些情况下，对于某些文件系统，rsync 可以使用 -X 复制每个压缩状态。 (2认同)

归档时间：	4 年，8 月前
查看次数：	3967 次
最近记录：	4 年，8 月前