windows或linux电脑为什么复制很多个大量小文件比复制总体积相同的单个大文件要慢很多，有时非常慢，很慢。甚至像卡住不动一样。但一旦复制大文件就快很多。这种现象即使是使用FastCopy这种快速复制文件的专用工具也是如此，曾试过用群晖Nas 色卡司Nas 局域网   本地硬盘  本地U盘 测试这两种复制都是如此

这个很无奈，我后来的解决办法：

1.我总结 如果是你复制的文件有 病毒或木马，可能被360或腾讯管家 卡住了 先关闭杀毒与安全软件  
2.如我复制的是QQ数据目录的小图片 小视频 聊天信息，非常慢，后来我就把整个QQ数据目录先压缩 成一个或多个压缩文件，再复制，然后再解压，秒快‘

3.或使用第三方压缩工具，无压缩比 

4.用好压的“存储”方式来把小文件直接打包拷贝（不是先打包，而是直接把包直接存到目的位置），速度会比较快。

5.rsync 会比较快，可尝试一下

在网上找了很多相关知识，感觉下面这个较可靠的一个说法

作者：知乎 时国怀

复制一个文件需要做的有1-3步：

1、在目标位置创建对应的文件名项，因为文件名也是要保存在磁盘上的；

2、如果文件有内容，把文件内容写入磁盘，并按照块对齐（512字节-64K不等）

3、如果文件有内容，在一个特定的位置把文件内容的块的信息记录下来，标记这些块属于这个文件并且是被使用了。

  如果是1M的文件，所以这三步都是需要的。对于1G的文件，需要的也是这三步，对于1024个1M的文件，需要的是1024×3步。

  对于磁盘设备有IOps的概念，就是每秒能执行的I/O次数，对于复制1024个1M文件来说，那么至少需要1024*3次I/O，对于1G的文件来说，至少需要3次。

  所以从次数来说，复制小文件越多，磁盘读写次数越多，虽然有cache等一系列优化的机制，但整体次数还是要高很多的。并且，磁盘写1字节，和写512字节（一个扇区）的代价是相同的，虽然写入文件名短，但仍然需要写入512字节（一个扇区）。

  因此写1G文件就至少要比写1024*1M文件多写512K这么多数据。如果说512K这么多数据好像也不太多，但还有一个不可忽略的操作就是比较文件名：复制文件的时候，需要判断是否有重名，复制1个文件，检查1次就可以了，复制1024个文件，就需要检查1024次，并且随着文件的增多，检查的负担也越重（要跟之前的文件都检查一下）。

所以总结下来有三点：

1、小文件导致IO次数增多，磁盘IO次数本身就有瓶颈；

2、小文件实际写入的内容也更多（这里我没包括索引项，实际索引项也很多，但不好表达）；

3、小文件导致CPU负担更重，需要匹配更多的信息。以上三点造成了小文件复制比大文件慢，所有操作系统的所有文件系统基本上都有以上三个原因

作者：知乎 刘贺 h8liu

技术方面，就说说机械硬盘吧。这东西的读写性能是很随机的一个事情，除了和是否是顺序读写有关之外，和寻道有关系，和存在里圈还是外圈也有关系，实际表现往往呈现很大的随机性。不信可以自己写个脚本测一测读写文件的速度，看在文件系统层能不能把读写时间浮动控制得很小。我当初上课做硬盘性能测量的时候都是要固定读写硬盘的某个物理位置才能得到比较稳定的数据。所以，问题里的这个现象，如果不把条件说清楚，别说解释为什么，连重复都很难。比如，我自己在Linux Ext4的机械硬盘上就无法重复这个现象。我在自己的home目录下拷贝1G文件的时间总是比1024个1M文件要慢若干秒。为什么会这样呢？可能的因素很多很复杂。最大的原因可能是因为Ext4是存Journal的，所以1024个小文件的很大部分还都在Journal里操作，离得很近，寻道很快，甚至是在同一个block里。而那个1G的文件却不会全存在Journal里，所以要反复在不同的位置读写硬盘，所以相对慢一点。如果是在Windows的FAT32下恐怕就是另一回事了，因为Journal没了。如果复制的源位置和目标位置是两块不同的硬盘又是另一回事了，因为现在读写是独立的两个寻道了。如果硬盘不是机械硬盘而是SSD就又是另一回事了，因为寻道没了。--说下楼下某个SSD测量的结果。我不知道那个工具具体测的是什么，但猜度起来，那个主要测量的性能差距应该是顺序读写和随机读写的区别。原因是因为各种介质（内存，硬盘，总线，等等……）上顺序读写都比随机读写要快（因为寻址常常是个力气活）。但这和大文件和若干小文件是不一样的。大文件不一定是顺序存的。一大堆小文件也不一定随机存的。

其它相关摘录资料

1.在Win上据说每复制一个文件都会校验一下，而很多小文件校验花的时间就会比较大了。
2.用过FTP的都知道。。复制一个执行一次命令，复制多个执行多个命令。
3.没人来回答一下rsync为啥那么快？

4.如果我们复制的文件数量很大的时候，由于每个文件在磁盘上存放的位置是不连贯的，所以复制这种数量级的文件是非常考验硬盘和U盘的随机读写性能的。
  而假如我们将大量文件添加到一个压缩包中，那么这些文件所占用的硬盘空间是连续的，这样传输的速度可以得到很大的提升。

5.Usb2.0（通用[即插即用]串行总线设备）是最大下行流量是6MB左右，而3.0是23MB左右，1.5是0.7MB左右。
   注意：这些数值都是估算值，这个也与你的电脑配置有关系。
   第三方复制软件easycopy原理就像是有一个1-9文件，他的复制方式是：
  1：4kb
  6：4kb
  7：8kb
  5：1MB
  9：10MB
  3：20MB
  2：48.5MB
  4：88MB
  8：1gb
  而内置复制方式则是顺序（名称）复制，某些第三方软件采用了这个方法，自然就快。

6.linux系统跨网络拷贝小文件，打包后再传递的方式很不可取，因为要来回写磁盘，打包到磁盘的时间比传输长。可考虑打包压缩时无压缩比
7.rsync和tar的方式都比较快，差距不大。scp的方式慢

以下内容摘自 v2ex 原文：https://www.v2ex.com/t/153834
1.昨天备份手机上的tencent文件夹，你知道的微信和手Q都是很多很多的文件夹和小文件来管理资源的，于是，我不知道花了多久，昨天晚上开始备份，今天早上起来的时候算是结束了，Windows显示剩余6小时的时候我就哭了，于是改用Cygwin的mv命令，但是也花了很久，目测一两个小时吧
PS：读卡器直接读卡的，没有用USB数据线传
PPS：不排除我的卡读写速度比较慢
2.无压缩比 打包成若干个压缩包文件，然后拷贝，解压。比你直接小文件对拷快很多  服务器对拷碎文件必备方法，省时间不是一点两点，但是记住不要压缩比。
3.大量小文件的问题来自于文件系统，现在的树形文件系统的遍历，增加节点可不是那么快的。
4. 因此建议还是将大量小文件进行打包。如果小文件并不复杂，比如源代码类，就算使用高压缩率打包也不会很慢
5.推荐7z，有个store的压缩模式。基本不压缩，速度飞快
6.我用它备份过整盘文件，速度不错，不过没试过大量小文件，下回测测速度~
7.临时文件和输出目录设到ramdisk 打包tar 一波带走
8.我会说我使用cpio么 备份gentoo时效率比tar高
   cp在大量小文件时，还是放弃吧
   全盘镜像的话么....没有比dd更优效率的了
9.teracopy或打包
10.我在用ExtremeCopy Pro，这个安装了就作为你的默认复制工具
11.rsync
电脑上装服务端，Android手机用命令客户端，然后Tasker根据不同情景调用。