Clonando um laptop por NVMe TCP

Artigo original ↗ Discussão no Hacker News ↗

Clonar o drive NVMe de um laptop pela rede usando NVMe-over-TCP gera debate sobre se a complexidade adicional do protocolo se justifica quando ferramentas mais simples como `dd` com `netcat`, rsync, Clonezilla ou `btrfs send/receive` muitas vezes bastam. Os comentários discutem trade-offs de desempenho (Wi‑Fi vs Ethernet vs links USB‑C/Thunderbolt, compressão, tamanhos de bloco, O_DIRECT), verificação de integridade dos dados e o impacto de criptografia de disco inteiro ou dados esparsos. Muitos observam que instalações modernas de Linux e até do Windows são surpreendentemente portáveis entre hardwares diferentes, então a verdadeira escolha é entre clonagem bruta em nível de bloco e métodos de migração em nível mais alto, baseados em arquivos ou snapshots, que evitam copiar espaço não utilizado.

Utilidade de NVMe/TCP vs Ferramentas Simples (nc, dd, ssh)

  • Muitos argumentam que NVMe/TCP não oferece nenhuma vantagem real para uma clonagem única de disco em um link lento; um pipeline simples dd | nc (ou dd | ssh) é mais simples e igualmente eficaz.
  • Outros destacam o valor do NVMe/TCP quando você realmente quer usar um NVMe remoto como dispositivo de bloco (como armazenamento em rede), e não apenas clonar.
  • Alguns veem o NVMe/TCP como “mais peças móveis” do que o necessário; outros o veem como um transporte limpo e padronizado.

Integridade de Dados, Flags do dd e Detalhes de Pipeline

  • Debate sobre opções do dd: alguns alertam para corrupção sem iflag=fullblock ao usar count, enquanto outros esclarecem que isso só é necessário em casos específicos (leituras parciais com count/skip).
  • Discussão sobre oflag=direct: um lado afirma que isso melhora ou não prejudica o desempenho com SSDs rápidos; outro diz que muitas vezes reduz a taxa sustentada e não traz benefício neste cenário de clonagem.
  • Sugestões para evitar o dd totalmente no lado de recepção e usar nc > /dev/nvme0nX ou pv para progresso e buffering.

Desempenho: Compressão, Tamanhos de Bloco, Redes

  • Muitos recomendam adicionar compressão (lz4, zstd, gzip) quando a rede é mais lenta que a CPU/disco, especialmente ao clonar discos esparsos ou majoritariamente vazios.
  • Ajuste do tamanho de bloco (bs=) é visto como importante para a taxa de transferência do dd; alinhar com tamanhos de dispositivo/setor pode importar.
  • Wi‑Fi é repetidamente apontado como um grande gargalo; Ethernet cabeada, adaptadores USB–Ethernet ou rede direta USB‑C/Thunderbolt podem ser muito mais rápidos.

Alternativas para Clonagem e Migração

  • Vários preferem Clonezilla, nbd/nbdkit ou ferramentas no estilo Acronis para cópia esparsa, verificações de integridade e redimensionamento de partições.
  • Outros defendem métodos em nível de sistema de arquivos: rsync, btrfs send/receive, dump/restore, configurações declarativas no estilo Ansible/NixOS, ou simplesmente mover o drive NVMe entre máquinas.

Considerações entre Hardware e SOs

  • Instalações Linux geralmente migram entre hardwares diferentes com poucos problemas; o Windows é relatado como mais capaz de lidar com mudanças de hardware do que antes, mas ainda pode enfrentar questões de licenciamento ou drivers.
  • Criptografia de disco vinculada ao TPM é apontada como um caso difícil e sem solução clara.