blocks|key|2725743|text|如果您的系统没有被它破坏(例如，文件可能在缓存中)，那么GNU并行http://www.gnu.org/software/parallel/可能适用于您：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2725744|find+.+-type+f+-print0+%7C+parallel+-0+-j10+cp+{}+destdir|code-block|syntax|javascript|2725745|这将运行10个并发的cps。|style|CODE|2725746|赞成:阅读起来很简单。|2725747|Con:+GNU并行在大多数系统上并不是标准的，所以您可能需要安装它。|2725748|如果您想保持目录结构：|2725749|find+.+-type+f+-print0+%7C
++parallel+-0+-j10+mkdir+-p+destdir/{//}';'+cp+{}+destdir/{//}|2725750|观看介绍视频以获得更多信息：http://www.youtube.com/watch?v=OpaiGYxkSuQ|2725751|关于并行磁盘I/O的讨论，请参见https://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/。|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gnu.org/software/parallel/|1|http://www.youtube.com/watch?v=OpaiGYxkSuQ|2|https://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/^0|X|11|0|0|0|A|2|0|0|0|0|0|E|16|1|0|G|20|2^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|D|3|E|5|F|7|1D|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1E|8|@$A|1F|B|1G|K|L]]|9|@]|C|$]]|$1|M|3|N|5|6|7|1H|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1I|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1J|8|@]|9|@]|C|$]]|$1|S|3|T|5|F|7|1K|8|@]|9|@]|C|$G|H]]|$1|U|3|V|5|6|7|1L|8|@]|9|@$A|1M|B|1N|1|1O]]|C|$]]|$1|W|3|X|5|6|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]]|Y|$Z|$5|10|11|12|C|$13|14]]|15|$5|10|11|12|C|$13|16]]|17|$5|10|11|12|C|$13|18]]]]

If you system is not thrashed by it (e.g. maybe the files are in cache) then GNU Parallel <a href="http://www.gnu.org/software/parallel/" rel="nofollow noreferrer">http://www.gnu.org/software/parallel/</a> may work for you:
<pre><code>find . -type f -print0 | parallel -0 -j10 cp {} destdir
</code></pre>
This will run 10 concurrent <code>cp</code>s.
Pro: It is simple to read.
Con: GNU Parallel is not standard on most systems - so you probably have to install it.
If you want to keep the directory structure:
<pre><code>find . -type f -print0 |
 parallel -0 -j10 mkdir -p destdir/{//}';' cp {} destdir/{//}
</code></pre>
Watch the intro video for more info: <a href="http://www.youtube.com/watch?v=OpaiGYxkSuQ" rel="nofollow noreferrer">http://www.youtube.com/watch?v=OpaiGYxkSuQ</a>
See also <a href="https://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/" rel="nofollow noreferrer">https://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/</a> for a discussion of parallel disk I/O.

blocks|key|431117|text|由于一个非常简单的原因，没有这样做的低级机制:这样做会破坏您的系统性能。与盘驱动器，每写将争夺位置的头部，导致大量的I/O等待。使用SSD，这将最终使一个或多个系统总线饱和，从而导致其他问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

There is no low-level mechanism for this for a very simple reason: doing this will destroy your system performance. With platter drives each write will contend for placement of the head, leading to massive I/O wait. With SSDs, this will end up saturating one or more of your system buses, causing other problems.

blocks|key|431187|text|唯一不会破坏机器响应的答案不是“副本”，而是非常快的。如果您不会在新的或旧的位置编辑这些文件，那么硬链接实际上就像一个副本，而且(只有)如果您在同一个文件系统上，它们就会很快创建。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431188|检查一下cp+-l，看看它是否对你有用。|offset|length|style|CODE|entityMap^0|0|4|5^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|J|8|@$D|K|E|L|F|G]]|9|@]|A|$]]]|H|$]]

The only answer that will not trash your machine's responsiveneess isn't exactly a 'copy', but it is very fast. If you won't be editing the files in the new or old location, then a hard link is effectively like a copy, and (only) if you're on the same filesystem, they are created very very very fast.

Check out <code>cp -l</code> and see if it will work for you.

blocks|key|431277|text|下面是一个分布式/并行和分散的文件复制工具，它将对文件进行分块处理，并并行复制所有块。只有当您有一个支持多个流的SSD或某种具有多个磁盘头的设置时，它才可能对您有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431278|https://github.com/hpc/dcp|offset|length|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|Q|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@$D|N|E|O|1|P]]|A|$]]]|F|$G|$5|H|I|J|A|$K|C]]]]

Here's a distributed/parallel and decentralized file copy tool that will chunk up the file and copy all of the chunks in parallel. It'll probably only help you if you have an SSD that supports multiple streams or some sort of setup with multiple disk heads.

<a href="https://github.com/hpc/dcp" rel="nofollow noreferrer">https://github.com/hpc/dcp</a>

blocks|key|431338|text|对于那些认为这不是个好主意的人，我会说这取决于。您可以拥有一个大型raid系统或一个并行文件系统，这将提供比一个cp进程所能处理的更好的性能。然后是的，你需要使用一个“并行工具”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431339|让我们以这个例子为例：|431340|timeout+10+strace+-e+write+-c+cp+/dev/zero+/dev/null
strace:+Process+24187+detached
%25+time+++++seconds++usecs/call+++++calls++++errors+syscall
------+-----------+-----------+---------+---------+----------------
100.00++++0.655188+++++++++++4++++166222+++++++++++write
------+-----------+-----------+---------+---------+----------------
100.00++++0.655188++++++++++++++++166222+++++++++++total|code-block|syntax|javascript|431341|然后是这个|431342|timeout+0.01+strace+-e+write++cp+/dev/zero+/dev/null
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
write(4,+"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,+65536)+=+65536
strace:+Process+24567+detached|431343|因此，在本例中，由"cp“编写的每个syscall写的是64+this，对于我的系统上的10s，我能够提供这个带宽:+65536*166222/10+=+1089352499+=~+1,08GB/s|431344|现在，让我们用2个进程启动这个工作负载(我有4个核心，但我的桌面用于其他东西，这里只是一个例子)：|431345|timeout+10+strace+-e+write+-c+cp+/dev/zero+/dev/null+&+timeout+10+strace+-e+write+-c+cp+/dev/zero+/dev/null+&++wait
[1]+26106
[2]+26107
strace:+Process+26113+detached
strace:+Process+26112+detached
%25+time+++++seconds++usecs/call+++++calls++++errors+syscall
%25+time+++++seconds++usecs/call+++++calls++++errors+syscall
------+-----------+-----------+---------+---------+----------------
------+-----------+-----------+---------+---------+----------------
100.00++++0.624108+++++++++++4++++162616+++++++++++write
100.00++++0.638468+++++++++++4++++162451+++++++++++write
------+-----------+-----------+---------+---------+----------------
100.00++++0.624108++++++++++++++++162616+++++++++++total
100.00++++0.638468++++++++++++++++162451+++++++++++total
------+-----------+-----------+---------+---------+----------------
[1]-++Exit+124++++++++++++++++timeout+10+strace+-e+write+-c+cp+/dev/zero+/dev/null|431346|因此，我们可以看到，我们可以使用2核心来启动这一性能的近一倍。|431347|因此，如果我们所处的环境不同于1xHard驱动器到1xHard驱动器，而是一个raid数组(或者多个NVMe+-这不是我同意的最常见的情况，但我每天都在处理这个问题)，那么并行使用多个公共驱动器肯定会显示出更好的性能。|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Z|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|15|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|16|8|@]|9|@]|A|$]]]|W|$]]

For the people who think that's not a great idea, I would say it depend.
You can have a big raid system or a parallel filesystem which will deliver really better performance than one cp process can handle. Then yes, you need to use a "parallel tool".

Let's take this example :

<pre><code>timeout 10 strace -e write -c cp /dev/zero /dev/null
strace: Process 24187 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.655188 4 166222 write
------ ----------- ----------- --------- --------- ----------------
100.00 0.655188 166222 total
</code></pre>

then this

<pre><code>timeout 0.01 strace -e write cp /dev/zero /dev/null
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) = 65536
strace: Process 24567 detached
</code></pre>

so each syscall write made by "cp" in this case is 64KiB and for 10s on my system I am able to deliver this bandwidth :
65536*166222/10 = 1089352499 =~ 1,08GB/s

Now, let's launch this workload with 2 process ( I have 4 core but my desktop is used for other stuff, and here it's just an example ) :

<pre><code>timeout 10 strace -e write -c cp /dev/zero /dev/null &amp; timeout 10 strace -e write -c cp /dev/zero /dev/null &amp; wait
[1] 26106
[2] 26107
strace: Process 26113 detached
strace: Process 26112 detached
% time seconds usecs/call calls errors syscall
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
------ ----------- ----------- --------- --------- ----------------
100.00 0.624108 4 162616 write
100.00 0.638468 4 162451 write
------ ----------- ----------- --------- --------- ----------------
100.00 0.624108 162616 total
100.00 0.638468 162451 total
------ ----------- ----------- --------- --------- ----------------
[1]- Exit 124 timeout 10 strace -e write -c cp /dev/zero /dev/null
</code></pre>

So we see we are able to near double the performance using 2 core to launch this.

So if we are in a context different than 1xHard drive to 1xHard drive but a raid array ( or multiple NVMe so not the most common case I agree but I work on this every day ), it show definitely a better performance to use multiple common in parallel.

I have a list of files I need to copy on a Linux system - each file ranges from 10 to 100GB in size.

I only want to copy to the local filesystem. Is there a way to do this in parallel - with multiple processes each responsible for copying a file - in a simple manner?

I can easily write a multithreaded program to do this, but I'm interested in finding out if there's a low level Linux method for doing this.

Parallel File Copy

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我有一个在Linux系统上复制的文件列表--每个文件的大小从10到100 in不等。我只想复制到本地文件系统。是否有一种方法可以以一种简单的方式并行地执行--每个进程负责复制一个文件？我可以很容易地编写一个多线程程序来完成这个任务，但是我想知道是否有一个低级的Linux方法来完成这个任务。

问并行文件复制
EN

回答 5

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问并行文件复制EN

回答 5

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问并行文件复制
EN