☰

复制到 USB 记忆棒真的很慢吗？

tag-icon • tag-icon usb
复制到 USB 记忆棒真的很慢吗？

当我将文件复制到 USB 设备时，它比在 Windows 中花费的时间长得多（相同的 USB 设备，相同的端口），它比 USB 1.0 速度（1MB/s）快，但比 USB 2.0 速度（12MB/s）慢得多。复制 1.8GB 需要 10 多分钟（应该不到 3 分钟）。我有两个相同的 SanDisk Cruzer 8GB 棒，两者都有同样的问题。我在相邻端口有一个超级天才 32GB USB SSD，它以预期的速度运行。

我在 GUI 中发现的问题是进度条几乎立即达到 90%，完成 100% 的速度稍慢，然后挂在那里 10 分钟。此时中断复制似乎会导致文件尾部损坏。如果我等待它完成，复制就会成功。

有什么想法吗？dmesg 输出如下：

[64059.432309] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd
[64059.526419] scsi8 : usb-storage 2-1.2:1.0
[64060.529071] scsi 8:0:0:0: Direct-Access     SanDisk  Cruzer           1.14 PQ: 0 ANSI: 2
[64060.530834] sd 8:0:0:0: Attached scsi generic sg4 type 0
[64060.531925] sd 8:0:0:0: [sdd] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[64060.533419] sd 8:0:0:0: [sdd] Write Protect is off
[64060.533428] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[64060.534319] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.534327] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.537988] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.537995] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.541290]  sdd: sdd1
[64060.544617] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.544619] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.544621] sd 8:0:0:0: [sdd] Attached SCSI removable disk

答案1

为什么在 Linux 中复制到我的 USB 驱动器这么慢（而在 Windows 中更快）？

原因 1. 文件缓存可以进行写入出现更慢或更快

我在 GUI 中看到的问题是进度条几乎立即达到 90%，然后稍微慢一点地完成到 100%，然后在那里挂起 10 分钟。

您需要了解的一件事是文件缓存。Linux（和 Windows）将使用原本“空”的 RAM 来缓存读/写操作，并使它们在后续访问中更快。将复制操作缓存到慢速设备会导致您看到的行为——“快速完成”实际上是写入缓存，然后它变慢并停止，因为实际将缓存中的数据（同步）刷新到慢速设备需要很长时间。如果您在此时中止，数据将被损坏（如您所指出的），因为同步从未完成。

在 Windows 中复制看起来可能更快（包括报告的 MB/秒速度），因为有时 Windows不会等待用于同步，并在数据写入缓存后立即宣布作业完成。

原因 2. 写入大量文件（尤其是小文件）很慢

复制1.8GB

由于闪存和文件系统的工作方式，写入非常大的文件时吞吐量（速度）最高。写入大量小文件，甚至包含多个小文件的混合数据都会大大减慢该过程。这也会影响硬盘，但程度较轻。

原因 3. USB 驱动器和 SSD 的写入速度无法比较

我在邻近端口有一个超级天才 32GB USB SSD，它以预期的速度运行。

  • 普通的 USB 驱动器通常由串行（顺序）写入的闪存芯片组成，并且没有任何自己的缓存。

  • 另一方面，SSD 包含一个控制器，用于写入闪存芯片平行线，使 USB 的吞吐量提高 2 倍或更多。

    • 如果您的 32GB SSD 有 4x 8GB 芯片，那么在任何写入操作中它仍然比 USB 记忆棒快 4 倍。
    • SSD还包含 RAM 缓存（如硬盘），因此它可以快速将传入的数据存储在缓存中并告诉操作系统已完成，同时它仍然必须将该数据实际写入闪存。

  • 因此，对于一个大文件，我们假设的具有 4x 结构的 32GB GB 的速度将提高 4 倍；对于许多小文件，速度将提高 10 倍或更多，因为它可以智能地将它们存储在其缓存中。

总结，这些就是为什么在 Linux 中文件复制到 USB 驱动器可能会变慢的原因。它实际上是因为硬件/驱动程序问题还是其他原因而变慢的......

对 Linux 和 Windows 之间的写入速度进行适当的比较

  • 首先，由于原因 3，请忘记 SSD。它们就像橘子和苹果一样。
  • 为了消除原因 1（缓存）和原因 2（小文件）的影响，您需要使用一个大于测试系统上的 RAM 数量的大文件进行测试。
  • 在 Linux 中，您可以使用 创建它dd if=/dev/urandom of=largetest bs=1M count=7500，这将为您提供一个 7500 MB 的测试文件。假设您的系统内存小于 4GB 左右，那就足够了。将其复制到新格式化的 Sandisk 8GB 棒上，然后计时。
  • 在 Windows 中重新启动，然后将内容largetest从 USB 复制到硬盘。再次重启（将其从缓存中删除）。然后格式化 USB 棒（同样是 vfat/FAT32！），并将内容largetest从硬盘复制到 USB 棒。
  • 时间上如何比较？

答案2

现在是 2019 年了，我仍然遇到同样的问题。所以我想我应该在网上搜索解决方案。我发现以下页面提供了一个解决方案：https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f

它说：

在控制台中执行以下命令，看看它是否能为您解决问题。您可能需要sudo su先获得所需的权限。

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

如果可行，您可以通过将两行粘贴到文件末尾来使此更改在重新启动后保持不变/etc/rc.local。

对我来说它有以下效果：

之前将大文件复制到 USB 驱动器时，一开始速度非常快（比如 60 MB/s），然后变得越来越慢（< 10 MB/s），直到看起来永远都无法完成。

现在它开始时比较慢，但速度越来越快，而且比以前更快完成。所以它似乎确实“解决”了问题，或者至少产生了积极的影响。

答案3

找到解决办法后，我所做的就是卸载、移除驱动器，然后sudo modprobe ehci_hcd在终端中运行。插入驱动器，然后再次sudo modprobe ehci_hcd插入驱动器，哇哦，20/mbs，我想分享一下。希望我不必每次都这样做……但这并不难……

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235 说他们已经修复了这个漏洞。

答案4

umount如果设备已经自动安装，则只需手动将其安装到即可/mnt/foldername。

就我而言，

umount /media/usb0
mount /dev/sdb1 /mnt/sam

此后，它应对得非常快。

相关内容