Cloning a Laptop over NVMe TCP

Original Article ↗ Hacker News Discussion ↗

Usefulness of NVMe/TCP vs Simple Tools (nc, dd, ssh)

  • Many argue NVMe/TCP offers no real advantage for a one-shot disk clone over a slow link; a plain dd | nc (or dd | ssh) pipeline is simpler and equally effective.
  • Others highlight NVMe/TCP’s value when you actually want to use a remote NVMe as a block device (like network storage), not just clone it.
  • Some view NVMe/TCP as “more moving parts” than necessary; others see it as a clean, standardized transport.

Data Integrity, dd Flags, and Piping Details

  • Debate about dd options: some warn about corruption without iflag=fullblock when using count, while others clarify it’s only needed in specific cases (partial reads with count/skip).
  • Discussion on oflag=direct: one side claims it improves or doesn’t hurt performance with fast SSDs; another says it often reduces sustained throughput and isn’t beneficial in this cloning scenario.
  • Suggestions to avoid dd entirely on the receive side and use nc > /dev/nvme0nX or pv for progress and buffering.

Performance: Compression, Block Sizes, Networks

  • Many recommend adding compression (lz4, zstd, gzip) when the network is slower than CPU/disk, especially when cloning sparse or mostly empty disks.
  • Block size tuning (bs=) is seen as important for dd throughput; matching device/sector sizes can matter.
  • WiFi is repeatedly noted as a major bottleneck; wired Ethernet, USB–Ethernet adapters, or direct USB‑C/Thunderbolt networking can be vastly faster.

Alternatives for Cloning and Migration

  • Several prefer Clonezilla, nbd/nbdkit, or Acronis‑style tools for sparse copying, integrity checks, and partition resizing.
  • Others advocate filesystem-level methods: rsync, btrfs send/receive, dump/restore, Ansible/NixOS-style declarative setups, or just moving the NVMe drive between machines.

Cross‑Hardware and OS Considerations

  • Linux installs generally migrate across different hardware with few issues; Windows is reported to handle hardware changes better than it used to but may hit licensing or driver quirks.
  • TPM‑tied disk encryption is flagged as a hard, unresolved case.