我目前正在使用以下命令将同事的日志文件的子集复制到另一个位置,以供我自己记录和进一步分析。
find . -name '*somestring*' -type f -exec cp -v --update -i {} '//anetworkdrive/logfiles/' \;
随着时间的推移,随着每个位置的文件数量的增长,速度变得越来越慢(显然),但似乎比我预期的要慢。
如果我time find . -name '*somestring*' -type f
在源文件夹和目标文件夹中运行,它会在每个位置找到<1,000个文件,这大约需要0.2秒(实际)。
在自上次运行以来两端均未发生任何变化的情况下,我本以为上述复制命令不会比单独执行 find 命令花费更多时间。它会find
在不到 1 秒的时间内返回文件列表,然后我认为cp --update
会非常快速地检查两个文件 (src、dest) 的修改日期,如果它们匹配则跳过。
但是,我的完整复制命令现在要花费将近一分钟的时间,让人怀疑它是否在进行比修改日期更详细的比较,例如完整差异等。
有人能向我解释为什么上述命令即使没有任何改变也需要这么长时间吗?
有没有更快的方法可以做到这一点?将查找结果通过管道传输到 cp 会更快吗?
谢谢。
答案1
好的,根据上面 Daniel B 的评论,我测试了三种方法。
我在本地驱动器到本地驱动器的传输中测试了这些方法,结果find . -name '*somestring*'
发现有 495 个文件,平均 5.8MB,总计 2.82GB。每种方法的第一个计时结果是目标目录为空,因此所有 495 个文件都已复制。第二个计时结果是目标已与源匹配,因此没有文件被复制。
1-使用 find 命令中的 exec:
time find . -name '*somestring*' -type f -exec cp -v --update -i {} -t '../dst/' \;
real 2m2.037s
real 0m35.043s
2-将文件列表直接传送到cp:
time find . -name '*somestring*' -type f -print0 | xargs -0 cp -v --update -t '../dst/'
real 1m42.354s
real 0m3.463s
3 - 使用rsync
time rsync -vh --update *somestring* '../dst/'
real 1m53.605s
real 0m2.300s
因此,在这种情况下,rsync
基本上与 打成平手cp
。但是,当我回到实际的应用程序(从一个网络位置复制到另一个网络位置)时,我发现rsync
占了上风。在我的实际场景中,当 dst 目录已经与 src 匹配时,管道到 大约需要 15 秒,而 则find
需要大约 7 秒。cp
rsync
所以就是 rsync!