为什么 dd 这么慢，bs 为 100M

Question

我只是尝试使用 dd 覆盖快速 ssd。使用我输入的 ubuntu 启动映像：

dd if=/dev/zero of=/dev/sda bs=100M
error writing '/dev/sda': No space left on device
blah blah
256 GB copied, 1195.81 s 214 MB/s

那不是很慢吗？瓶颈在哪里？块大小的选择呢？

Answer 1

的最佳块大小dd约为64k- 256k，人类通常更喜欢1M。

没有真正 I/O 的基准测试：

$ for bs in 512 4k 16k 64k 128k 256k 512k 1M 4M 16M 64M 128M 256M 512M
> do
>     echo ---- $bs: ----
>     dd bs=$bs if=/dev/zero of=/dev/null iflag=count_bytes count=10000M
> done
---- 512: ----
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 4.2422 s, 2.5 GB/s
---- 4k: ----
2560000+0 records in
2560000+0 records out
10485760000 bytes (10 GB) copied, 0.843686 s, 12.4 GB/s
---- 16k: ----
640000+0 records in
640000+0 records out
10485760000 bytes (10 GB) copied, 0.533373 s, 19.7 GB/s
---- 64k: ----
160000+0 records in
160000+0 records out
10485760000 bytes (10 GB) copied, 0.480879 s, 21.8 GB/s
---- 128k: ----
80000+0 records in
80000+0 records out
10485760000 bytes (10 GB) copied, 0.464556 s, 22.6 GB/s
---- 256k: ----
40000+0 records in
40000+0 records out
10485760000 bytes (10 GB) copied, 0.48516 s, 21.6 GB/s
---- 512k: ----
20000+0 records in
20000+0 records out
10485760000 bytes (10 GB) copied, 0.495087 s, 21.2 GB/s
---- 1M: ----
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 0.494201 s, 21.2 GB/s
---- 4M: ----
2500+0 records in
2500+0 records out
10485760000 bytes (10 GB) copied, 0.496309 s, 21.1 GB/s
---- 16M: ----
625+0 records in
625+0 records out
10485760000 bytes (10 GB) copied, 0.972703 s, 10.8 GB/s
---- 64M: ----
156+1 records in
156+1 records out
10485760000 bytes (10 GB) copied, 1.0409 s, 10.1 GB/s
---- 128M: ----
78+1 records in
78+1 records out
10485760000 bytes (10 GB) copied, 1.04533 s, 10.0 GB/s
---- 256M: ----
39+1 records in
39+1 records out
10485760000 bytes (10 GB) copied, 1.04685 s, 10.0 GB/s
---- 512M: ----
19+1 records in
19+1 records out
10485760000 bytes (10 GB) copied, 1.0436 s, 10.0 GB/s

• 默认512字节非常慢（每 512 字节两个系统调用对 CPU 来说太多了）
• 4k 比 512
• 16k 比 4k
• 64k-256k和它得到的一样好
• 512k-4M稍慢
• 16M-512M速度减半，比4k.

我的猜测是，从特定大小开始，由于缺乏并发性，您开始失去速度。dd 是单个进程；并发主要由内核提供（预读、缓存写入等）。如果它必须先读取 100M 才能写入 100M，则会有设备闲置的时刻，等待另一个完成读取或写入。块大小太小，您会遭受纯粹的系统调用开销，但是在 64k 左右时完全消失。

在从同一设备复制或复制到同一设备时，100M 或更大的块大小可能会有所帮助。至少对于硬盘驱动器，这样做应该减少浪费在查找上的时间，因为它不能同时在两个地方。

为什么你首先要像这样覆盖你的SSD？通常，您会尽量避免对 SSD 进行不必要的写入；如果它考虑到所有已使用的空间，它也可能会失去一些性能，直到您再次修剪它。

您可以改用此命令来修剪/丢弃整个 SSD：

blkdiscard /dev/sda

如果您的 SSD 在 TRIM 之后具有确定性读取零（您可以检查的属性hdparm -I），它看起来像是充满了零，但 SSD 实际上将其所有块视为免费的，这应该为您提供最佳性能。

TRIM 的缺点是，如果已删除的文件已被丢弃，您将失去所有恢复数据的机会......