☰

为什么 Clonezilla 比 dd 更快？

tag-icon • tag-icon dd disk-image clonezilla
为什么 Clonezilla 比 dd 更快？

在我的 SSD 映像（源和目标是 2 个 SSD）上，使用 CloneZilla 时我获得 12GBpm，而使用 dd 时我仅获得 5GBpm。
是什么让 Clonezilla 比 dd 快这么多？

答案1

dd 只是从块 0 读取到块 99999 并复制数据。

Clonezilla 了解文件系统，并且知道何时没有任何内容需要复制（因为那是空白空间或已删除文件的数据）。

一旦您知道不要复制所有无用的数据，复制真实数据就变得容易得多。

来自网络页面“对于不受支持的文件系统，扇区到扇区的复制由 Clonezilla 中的 dd 完成。”

答案2

嗯，这取决于 Clonezilla 使用什么来进行克隆。

它根据分区的类型使用不同的工具，这些工具取自他们的网站：

Based on Partclone (default), Partimage (optional), ntfsclone (optional), or dd to image or clone a partition.

它通常会按该顺序使用它们来尝试复制您的分区。dd 是最后的手段，因为它只是逐个扇区复制，并且没有内置任何基于分区文件系统类型的优化。例如，克隆 ntfs 分区比克隆 hfs 分区要快得多（至少使用旧版本的 clonezilla，有一段时间没用了），因为没有内置工具可以高效地复制 hfs+，并且它使用了 dd。

答案3

由于多种原因，Clonezilla 可能比 dd 更快。

  1. 使用的硬件
  2. 使用的软件（Partclone、partimage、ntfsclone、dd）
  3. dd的参数及设置

我同意前面提到的两个答案。我将重申并巩固这两个答案。

假设一切都是 1:1 的对应关系，其中 CloneZilla 使用 dd，而某人手动使用 dd，而不是 CloneZilla 使用 partclone 或类似物，我会说它一定是 dd 的参数，因为那将是唯一剩下的区别，假设所使用的硬件和软件是相同的。

一个参数是块大小。通常，块大小越大，复制速度越快，但有一个临界点，因此只选择最大的块大小并不总是明智的。

dd if=/dev/sda of=/dev/sdb bs=<value>

BS值如何提高速度：“dd”中的“bs”选项真的能提高速度吗？

在这种情况下，两者都不一定会复制空白扇区。这可能是性能差异中最大的问题。大多数用户可能不会在复制完最后一个分区的末尾后停止克隆。他们可能会使用这个基本命令

dd if=/dev/sda of=/dev/sdb

这不会在最后一个分区的末尾停止。

要在最后一个分区的末尾停止传输：

fdisk -l

然后复制源驱动器最后一个分区的 END 列中的值。然后将 count 设置为等于该值。

dd if=/dev/sda of=/dev/sdb count=<'fdisk -l' END_column_last_parition_result>

一旦所有分区数据匹配，这将停止逐字节复制。分区内可能存在空白数据，这会进一步降低性能。

如果可以，请在运行 dd 之前对驱动器进行碎片整理和压缩，以删除分区中的空白空间。压缩将使分区更小，并允许您更快地进行复制，因为您不会复制空白区域。

请注意，当您执行此操作时，您必须在 dd 操作之后扩展目标驱动器上的分区，以使未分配的可用空间可用。

您还可能会看到性能差异，因为磁盘上可能存在错误。

此外，参数“conv=sync”添加了填充，这会增加目标驱动器的数据消耗。它还使驱动器与源驱动器不“相同”。

如果从坏驱动器复制，通常使用 conv=sync,noerror。如果此驱动器良好，则只需 noerror 或不使用 conv= 就足够了。

因此，对于一个坏的驱动器，我会使用类似

dd if=/dev/sda of=/dev/sdb bs=512 count=<value> status=progress conv=sync,noerror

一个好的

dd if=/dev/sda of=/dev/sdb bs=10M count=<value> status=progress

相关内容