USB 3 写入速度慢

Question 1

你真的需要FAT吗？根据我的经验，FAT 驱动程序的 Linux 实现似乎按顺序访问设备，导致某些设备的性能非常差。我发现某些闪存设备在格式化为 ext4 时性能提高了 10 倍。

考虑到您在评论中提供的链接（http://www.beginninglinux.com/home/machine-lated/sandisk-extreme-64-usb-3-speed-test-benchmark-review）正在测试没有分区的读写速度，可能是你的闪存设备在linux FAT驱动程序访问时性能较差。如果这是真的，那么它的随机 IO 性能通常也很差。

您可以使用测试设备性能fio。切换到要测试的设备内的某个目录，并运行以下命令来测试混合随机 4k 读/写性能的性能：

fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

这将创建 500 MB 的测试文件test.img，然后开始以队列深度为 1 的随机 4 KB 块进行读写。size如果您的设备具有巨大的内部缓存，请增加。此测试的最长运行时间为 60 秒。请将此视为您设备的最坏情况。一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=1041.4MB, bw=17773KB/s, iops=4443, runt= 60001msec
...
write: io=1038.5MB, bw=17723KB/s, iops=4430, runt= 60001msec
...

要测试最佳情况，您可以增加块大小并使用 iodepth=32 执行 2 个并行进程：

fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=2 --runtime=60 --group_reporting

一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=10892MB, bw=457088KB/s, iops=892, runt= 24401msec
...
write: io=9588.0MB, bw=402365KB/s, iops=785, runt= 24401msec
...

当然，如果你真的想要高分，你应该用高io深度进行顺序阅读。这应该接近您在设备规格表中看到的数字（也就是说，在现实生活中永远不会）：

fio --name TEST --eta-newline=5s --filename=test.img --rw=read --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=10240MB, bw=1468.8MB/s, iops=2937, runt=  6972msec
...

请注意，这低于规格表（大约 2 GB/s），因为我已将 I/O 调度程序配置为尽可能低的延迟（带有和的deadlineI/O 调度程序）。1 > ../queue/iosched/fifo_batch50 > ../queue/iosched/read_expire

请注意最坏情况（约 17 MB/s）和最佳情况（约 1470 MB/s）之间的巨大差异。

Answer

你真的需要FAT吗？根据我的经验，FAT 驱动程序的 Linux 实现似乎按顺序访问设备，导致某些设备的性能非常差。我发现某些闪存设备在格式化为 ext4 时性能提高了 10 倍。

考虑到您在评论中提供的链接（http://www.beginninglinux.com/home/machine-lated/sandisk-extreme-64-usb-3-speed-test-benchmark-review）正在测试没有分区的读写速度，可能是你的闪存设备在linux FAT驱动程序访问时性能较差。如果这是真的，那么它的随机 IO 性能通常也很差。

您可以使用测试设备性能fio。切换到要测试的设备内的某个目录，并运行以下命令来测试混合随机 4k 读/写性能的性能：

fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

这将创建 500 MB 的测试文件test.img，然后开始以队列深度为 1 的随机 4 KB 块进行读写。size如果您的设备具有巨大的内部缓存，请增加。此测试的最长运行时间为 60 秒。请将此视为您设备的最坏情况。一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=1041.4MB, bw=17773KB/s, iops=4443, runt= 60001msec
...
write: io=1038.5MB, bw=17723KB/s, iops=4430, runt= 60001msec
...

要测试最佳情况，您可以增加块大小并使用 iodepth=32 执行 2 个并行进程：

fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=2 --runtime=60 --group_reporting

一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=10892MB, bw=457088KB/s, iops=892, runt= 24401msec
...
write: io=9588.0MB, bw=402365KB/s, iops=785, runt= 24401msec
...

当然，如果你真的想要高分，你应该用高io深度进行顺序阅读。这应该接近您在设备规格表中看到的数字（也就是说，在现实生活中永远不会）：

fio --name TEST --eta-newline=5s --filename=test.img --rw=read --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

一个相当快的闪存设备（Intel SSD 910）在这里得到以下结果：

...
read : io=10240MB, bw=1468.8MB/s, iops=2937, runt=  6972msec
...

请注意，这低于规格表（大约 2 GB/s），因为我已将 I/O 调度程序配置为尽可能低的延迟（带有和的deadlineI/O 调度程序）。1 > ../queue/iosched/fifo_batch50 > ../queue/iosched/read_expire

请注意最坏情况（约 17 MB/s）和最佳情况（约 1470 MB/s）之间的巨大差异。

Question 2

由于没有更好的答案，我只是想指出，您的值对于一般闪存驱动器来说非常好，并且完全在您的特定闪存驱动器的预期范围内。

诸如 190MB/s 写入速度之类的营销值一般来说是不可持续的（它们最多有效几秒钟，直到内部缓冲区被填满，并且不反映实际的闪存性能），并且仅适用于顺序写入。一旦涉及文件系统，速度就会大大降低。即使在高级快速 USB 驱动器上，随机访问写入速度通常也低于 1MB/s，因此少量随机写入（如文件系统通常要求的那样）就会破坏写入性能。

您可以尝试使用对闪存更友好的文件系统，例如 f2fs（建议使用 4.4 或更高版本的内核），它在减少随机写入方面做得很好，看看是否有帮助。

Answer

由于没有更好的答案，我只是想指出，您的值对于一般闪存驱动器来说非常好，并且完全在您的特定闪存驱动器的预期范围内。

诸如 190MB/s 写入速度之类的营销值一般来说是不可持续的（它们最多有效几秒钟，直到内部缓冲区被填满，并且不反映实际的闪存性能），并且仅适用于顺序写入。一旦涉及文件系统，速度就会大大降低。即使在高级快速 USB 驱动器上，随机访问写入速度通常也低于 1MB/s，因此少量随机写入（如文件系统通常要求的那样）就会破坏写入性能。

您可以尝试使用对闪存更友好的文件系统，例如 f2fs（建议使用 4.4 或更高版本的内核），它在减少随机写入方面做得很好，看看是否有帮助。

Question 3

我将在这里给你一点希望。我正在查看 UHS-II SD 卡和 USB 读卡器，并从 Ubuntu“磁盘”小程序基准测试选项卡中观察到以下内容：

Ubuntu 14.04 - 内核 4.4 - 读取 ~140MB/s，写入 ~50MB/s
Ubuntu 17.04 - 内核 4.10 - 读取 ~270MB/s 写入 ~200MB/s

它们使用传统的“USB 大容量存储驱动程序”。这两点之间内核发生了一些变化，加速了大容量存储驱动程序的速度。

通常的评论重新基准测试适用，但是我们的内部应用程序比基准时间快了大约 10%，因此它们很好地代表了许多用例。

USB 外部硬盘实际上可能使用通用大容量存储驱动程序的替代驱动程序，因此您不能总是直接比较它们。

Answer

我将在这里给你一点希望。我正在查看 UHS-II SD 卡和 USB 读卡器，并从 Ubuntu“磁盘”小程序基准测试选项卡中观察到以下内容：

Ubuntu 14.04 - 内核 4.4 - 读取 ~140MB/s，写入 ~50MB/s
Ubuntu 17.04 - 内核 4.10 - 读取 ~270MB/s 写入 ~200MB/s

它们使用传统的“USB 大容量存储驱动程序”。这两点之间内核发生了一些变化，加速了大容量存储驱动程序的速度。

通常的评论重新基准测试适用，但是我们的内部应用程序比基准时间快了大约 10%，因此它们很好地代表了许多用例。

USB 外部硬盘实际上可能使用通用大容量存储驱动程序的替代驱动程序，因此您不能总是直接比较它们。

Question 4

我知道这有点过时了，但是

通过 USB 3 将 ubuntu 服务器 20.04 备份到 12T Seagate 扩展驱动器时，我感到非常沮丧。传输速度通常以千字节为单位报告。每隔 20 秒左右，一切就会停滞 10 到 15 秒。我怀疑是某种缓存写入。

解决方案？近几个月来，我在网络上尝试了多种方法，包括将 NTFS 格式更改为 ext4、修改缓存设置、更改电缆等。如果您受到影响，我相信您也遇到过这种情况。没有任何帮助。

昨天我把硬盘从机箱里拿出来了。它被标记为梭子鱼。我将磁盘放入台式电脑上的 USB 3 扩展坞中，并通过 LAN 启动 rsync 备份。 Bingo - 出色的连续传送速度

我得出的结论是，问题在于 Seagate 扩展机箱中的控制器，而不是 Linux。扩展硬盘在插入 Windows 10 时表现良好，这表明它也可能针对该系统进行了优化。

我现在已将扩展坞移至 Ubuntu 服务器上的 USB 3 端口，目前的备份速度约为 50MB/s

我可以忍受这一点。

Answer

我知道这有点过时了，但是

通过 USB 3 将 ubuntu 服务器 20.04 备份到 12T Seagate 扩展驱动器时，我感到非常沮丧。传输速度通常以千字节为单位报告。每隔 20 秒左右，一切就会停滞 10 到 15 秒。我怀疑是某种缓存写入。

解决方案？近几个月来，我在网络上尝试了多种方法，包括将 NTFS 格式更改为 ext4、修改缓存设置、更改电缆等。如果您受到影响，我相信您也遇到过这种情况。没有任何帮助。

昨天我把硬盘从机箱里拿出来了。它被标记为梭子鱼。我将磁盘放入台式电脑上的 USB 3 扩展坞中，并通过 LAN 启动 rsync 备份。 Bingo - 出色的连续传送速度

我得出的结论是，问题在于 Seagate 扩展机箱中的控制器，而不是 Linux。扩展硬盘在插入 Windows 10 时表现良好，这表明它也可能针对该系统进行了优化。

我现在已将扩展坞移至 Ubuntu 服务器上的 USB 3 端口，目前的备份速度约为 50MB/s

我可以忍受这一点。

USB 3 写入速度慢

答案1

答案2

答案3

答案4

相关内容