1

假设我们有一个遵循Mike Rubel 建议的 rsync 方法的自定义备份服务。为了进行备份轮换，cp必须使用此命令：

cp -al source target

有了这个，我试图旋转一个 35GB 的目录，其中有很多小文件（~5KB-200KB），即一个非常大的树目录。问题是它至少持续五个小时。这对我来说似乎很多，特别是通过使用该-l选项。

SATA 磁盘的这种行为是否正常？组合标志是否会-al导致 cp 命令中的额外开销导致该延迟？

谢谢！

4

1 回答 1

1

如果文件大小都在 2 GB 左右，我认为这非常慢。如果文件大小都在 200 字节左右，我认为这很快。好吧，在我认为这个速度很快之前，我实际上并不知道文件必须有多小，但如果它们都非常小，你的驱动器将花费大部分时间来寻找、读取元数据、写入元数据，提交期刊，等等。

但这听起来令人沮丧，无论哪种方式。

一些想法立即浮现在脑海：

  • a_time如果您不使用任何东西，您可以关闭相关特定文件系统的正常a_time运行时间。（将noatime mount(8)选项添加到您的fstab(5)文件中。）这将防止在复制操作的“读取”端出现大量非常小的分散写入。这可能会减少一小部分时间。5%？10%？也许更多？好的一面是它需要几秒钟才能使用mount(8) -oremount,noatime然后找出来。:)

  • 您可以使用硬链接而不是副本。（cp(1)提到了-l使用链接的命令行选项——我必须不​​好意思地承认我从未尝试过，我一直使用 链接ln(1)，但是为数十万个文件这样做听起来很不有趣。所以尝试-l并cp(1)报告回来。： ) 使用硬链接的好处是 (a) 节省了磁盘空间 (b) 节省了磁盘带宽——只有元数据被读取/写入，这可能会快数千倍。它可能不是您想要的工具，它实际上取决于您的应用程序在备份操作运行时如何修改数据。

  • 你可以想出一些更聪明的替代品来代替整个东西。rsync是一个很好的工具，但不是非常出色。git(1)可能是您任务的更智能工具。根本不制作副本，这可能会快得多。

  • 您可以使用一些聪明的块设备技巧：例如，LVM快照，以允许您的备份操作与使用并行进行，并在备份完成时删除快照。如果您的数据没有太多变动，这应该会明显更快。如果有很多流失，它可能只会稍微好一点。但它会让你的 rsync 立即开始，而不是五小时窗口的另一边。

于 2011-02-23T08:25:35.790 回答