通过 NVMe TCP 克隆笔记本电脑

原文 ↗ Hacker News 讨论 ↗

NVMe/TCP 与简单工具（nc、dd、ssh）的实用性

  • 许多人认为，对于通过慢速链路进行一次性磁盘克隆，NVMe/TCP 并没有真正优势；一个普通的 dd | nc（或 dd | ssh）管道更简单，也同样有效。
  • 也有人强调，NVMe/TCP 的价值在于你真正想把远端 NVMe 当作块设备来使用（像网络存储一样），而不只是克隆它。
  • 有些人把 NVMe/TCP 看作“比必要更多的组件”；另一些人则认为它是一种干净、标准化的传输方式。

数据完整性、dd 标志与管道细节

  • 关于 dd 选项存在争论：有人警告说，在使用 count 时如果没有 iflag=fullblock 可能会导致损坏；另一些人则澄清，只有在特定情况下（带 count/skip 的部分读取）才需要它。
  • 关于 oflag=direct 的讨论：一方声称它在快速 SSD 上会提升性能或至少不会有害；另一方则说它通常会降低持续吞吐量，在这种克隆场景下没有好处。
  • 还有人建议在接收端完全不要用 dd，而是用 nc > /dev/nvme0nX，或者用 pv 来显示进度并缓冲。

性能：压缩、块大小、网络

  • 许多人建议在网络比 CPU/磁盘更慢时加入压缩（lz4、zstd、gzip），尤其是在克隆稀疏或大多为空的磁盘时。
  • bs= 的块大小调优被认为对 dd 吞吐量很重要；匹配设备/扇区大小可能会有影响。
  • WiFi 被反复指出是主要瓶颈；有线以太网、USB–以太网适配器，或直接使用 USB‑C/Thunderbolt 网络连接，速度可能快得多。

克隆与迁移的替代方案

  • 许多人更喜欢 Clonezilla、nbd/nbdkit，或 Acronis 风格的工具，因为它们支持稀疏复制、完整性检查和分区调整大小。
  • 其他人则主张文件系统级方法：rsync、btrfs send/receive、dump/restore、Ansible/NixOS 风格的声明式配置，或者干脆把 NVMe 硬盘直接从一台机器移到另一台机器。

跨硬件与操作系统的考虑

  • Linux 安装通常可以在不同硬件之间迁移，且问题很少；Windows 据说比以前更能应对硬件变化，但仍可能遇到许可或驱动方面的怪癖。
  • 绑定 TPM 的磁盘加密被标记为一种棘手且尚未解决的情况。