我正在编写一个程序来移动分区的位置，只是为了好玩。它基本上通过读取分区方案（例如 GPT 或 MBR）来找到分区，然后读取512B分区的一个扇区（），然后将其写入新位置。但由于某种原因，这个过程非常慢，实际上这个驱动器的速度高达 2GB/s，但这个过程只以 700KB/s 的速度进行。是因为我应该一次读取/写入更大的原始数据吗？为什么？还有其他技巧可以加快速度吗？它正在测试HP P900 1TB Portable SSD。我还编辑了代码，使其使用 1 个完整的 SSD 页面进行读写，即4096B。性能确实提升到了8Mb/s，但这仍然远远没有达到我期望的性能。然后我让它每轮移动 1 Gib，它能够达到 1Gib/S 的速度。但由于 SSD 的页面大小只有 4KB，为什么4kib一次读写和一次1gib读写之间的性能会有差异呢？
对于小尺寸（512 字节）的数据，您至少需要移动数百兆字节，而 4096 字节扇区的问题就出现了 - 在实际情况下，您要读取 4096 字节的源数据，然后读取目标数据（4096 B），将 512 字节添加到其中，然后再次写入 4096 字节。SSD 磁盘有 4096 个扇区，因此当您仅移动 512 字节时，驱动器将需要读取 4096 字节。它就是这样设计的。
此外，当您移动兆字节时，您应该注意是来回移动数据还是移动数据。如果是向后移动 - 您不应该覆盖下一个要移动的数据。如果是向前移动 - 这里没有问题。这在 memcpy 汇编指令中得到了解决，如果目标数据在 RAM 中的位置较早（此处在磁盘上），它将从末尾移动数据，而不是从开头移动。
因此，您的解决方案是移动更多数据，我说的是一次移动 100 MB。到达分区末尾时停止移动那么多数据，然后只移动部分数据。最后，如果您将数据移回，则必须从末尾移动，而不是从开头移动。仅当您覆盖读取的相同空间时。
移动 512 个字节时，您会在两件事上浪费大量时间：
很可能您大部分的时间都花在发出读/写请求上，而不是实际读取/写入任何内容。
如果我的计算正确，那么 2 GB/s 相当于读取 512 字节大约需要 0.3µs，但每个请求总是有一个非零的延迟，我认为大约是 100µs？——因此，如果您使用单独的 512 字节请求（0.3×2048 + 100×2048）读取一兆字节，那么您总时间的 99.997% 都“浪费”在发出请求上。
同时，如果您发出单个 1 MB 读取请求（0.3×2048 + 100×1），则发出请求的开销仅为 14%，而 128MB 读取的开销为 0.1%。[这些是非常近似的数字。]
（对于 HDD 来说，速度同样会很慢 - 现代 SATA HDD 只要读取连续的块就可以以 ~200 MB/s 的速度读取或写入，但如果您每次都强制它从“读取”位置搜索到“写入”位置，那么很容易将总时间的 90% 用于移动磁头，而不是实际读取/写入。）
因此，“诀窍”实际上就是提出更大的请求并减少请求的数量。