假设我们有一个跟随rsync approach suggested by Mike Rubel的自定义备份服务。要进行备份轮换，必须使用此cp命令：
cp -al source target
有了这个，我正在尝试旋转一个35GB的目录，它有很多小文件（~5KB-200KB），即一个非常大的树目录。问题是它至少持续五个小时。对我来说似乎很重要，特别是使用-l选项。
SATA磁盘的行为是否正常？ -al组合标志是否会导致cp命令产生额外开销导致延迟？
谢谢！
答案 0 :(得分：1)
如果文件的大小都在2千兆字节左右，我认为这很慢。如果文件大小都在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立即开始，而不是五小时窗口的另一边。