我有一个非常大的 Maildir，正在使用 rsync 将其复制到一台新机器（超过 100BASE-T）。进度很慢。非常慢。大约慢 1 MB/s。我认为这是因为有很多小文件正在以本质上随机的顺序读取，相对于块在磁盘上的存储位置，这会导致大规模的寻道风暴。当我尝试 tar 目录时，我得到了类似的结果。有没有办法让 rsync/tar 按磁盘块顺序读取，或者以其他方式解决这个问题？
编辑：我尝试了 tar cf /dev/zero Maildir/，在旧系统上，这花了 30 分钟！在新系统上，当 rsync 最终完成时，相同的测试花了 18 分钟。在旧系统上转储同一目录花了 8 分钟，而在新系统上，dump -0f /dev/zero -b 1024 /home/psusi/Maildir/ 仅用 30 秒就完成了。
答案1
我最终编写了一个小的 Python 脚本来计算目录名称和 inode、inode 和数据块以及目录名称和数据块之间的相关性。结果表明，ext4 中文件名在目录中出现的顺序与它们在磁盘上的存储位置之间的相关性往往很差。在 ext4 邮件列表中讨论后，发现这是使用散列目录索引来加速大型目录中的查找的结果。名称以散列顺序存储，这实际上打乱了它们相对于其他任何内容的顺序。
在我看来，以及至少另一位评论者认为这是 fs 的一个缺陷，应该修复。Ted Ts'o（ext 维护者）认为在 fs 中执行此操作太困难，而好的工具（如 rsync 和 tar）应该有一个选项，可以在读取文件之前按 inode 编号对目录进行排序。
因此看起来需要为 rsync 和 tar 提交功能增强请求。
答案2
需要考虑的几点：
我们谈论的文件数量是多少？
find /path/to/your/maildir/ | wc -l应该可以给你一个大概的指示。数十万个应该没问题。数亿个可能意味着你需要修剪、存档和清理。磁盘是否很慢？有许多基准测试可用，例如全面的基准测试
bonnie++以及快速简单的磁盘实用程序基准测试程序。运行一个，看看您是否遇到了麻烦。- 这可能会引发硬件问题 - 更换更快的硬件
- 文件系统问题——您是否正在使用已知在高随机读取 IOPS 下速度非常慢的东西？
但最终还是tar要振铃然后转接应该为您提供最佳的总体吞吐量，但代价是您需要在生成 tar 后在现场设置传输。
答案3
尝试在新磁盘分区上禁用 atime 跟踪或使用相对 atime。这将限制开销。从非日志文件系统（如 ext2）更改为日志文件系统（如 ext3 或 ext4）会对性能造成一些影响
当我移动 Maildirs 时，我做了一个预备性的 rsync 来提前将所有目录放到位。然后，只需要进行更新。
当您准备好进行实际移动时，您可能需要确保目录是稳定的。
- 将 SMTP 守护进程置于仅队列模式，
- 禁用 SMTP 守护进程的队列运行，以及
- 禁止用户访问。
文件移动完成后重新激活。
编辑：我认为您已经确定了问题所在。Tar 和 rsync 都会遍历目录。由于 Maildir 中的正常文件更改，每个目录的文件最终会分散在磁盘上。像 dump 这样的工具会按块顺序读取分区，但会将问题复制到新分区。第二个 rsync 的运行速度应该比第二个快得多。