Como maximizar a velocidade de clonagem de disco via 'dd'?

Question

Eu quero copiar o disco inteiro de / dev / sda para / dev / sdb com precisão, então eu gostaria de usar o comando dd no Linux, mas há duas opções confusas, bs e sync .

dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync

• Devo adicionar a opção sync como wiki.archlinux.org sugerido ?

• Devo definir bs=16384kB como o tamanho do cache de disco em vez do número maior para maximizar a velocidade?

Answer 1

Should I add sync option as wiki.archlinux.org suggested?

Se você for usar a opção conv=noerror , é melhor usar o conv=sync com ele ou pode acabar com um backup inútil.

Pela página man do Linux

Each CONV symbol may be: 
...
sync
    pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs 

Essa opção que pode adicionar preenchimento é necessária ao especificar também a opção noerror ou "continuar após erros de leitura". O controlador de disco não fornece dados de setor para o buffer de entrada quando ocorre um erro de leitura difícil (isto é, irrecuperável). Se dd for terminado em tal erro (como normalmente faria), então a falta de dados não é um problema.

No entanto, quando "continuar após erros de leitura" é especificado, a falta de dados é um problema. Se o buffer de entrada não for preenchido para considerar o (s) setor (es) que é ilegível, os dados subseqüentes que serão gravados serão compensados dos setores apropriados para os quais devem ser gravados. Ou, se os dados subseqüentes pulassem os setores de destino correspondentes aos erros (ou se um buscasse (no jargão dd ) para seu setor correspondente), então os dados de lixo naqueles setores ignorados seriam tratados como cópias de dados originais.

Se você estava usando o dd para copiar blocos que tinham um número de seqüência integral, o preenchimento pode não ser necessário para detectar ou considerar os blocos ausentes. Não se pode presumir que os setores de discos brutos tenham tal numeração de seqüência integral e exigem preenchimento para tentar preservar a integridade do sistema de arquivos copiado.

Observe que há duas opções sync disponíveis com dd .
Um é conv=sync e o outro é iflag=sync . Eles têm significados diferentes.

Should I set bs=16384kB as the disk cache size rather than the larger number to maximize the speed?

A que "maior número" você está se referindo?

O parâmetro bs , tamanho do bloco, não tem nada a ver com o tamanho do cache (embora não tenha certeza de qual cache você está se referindo). 16MB é provavelmente um exagero, já que pode não haver muita memória DMAable disponível para bloquear. Existem alguns testes de benchmark para variar o tamanho do bloco e os que eu vi, como este , confirma minha suspeita de que há um tamanho de retorno diminuindo (ou pelo menos não mais), que parece ser de cerca de 512KB.

Um valor clássico para bs ao copiar um HDD costumava ser o tamanho da trilha em bytes (ou num_of_sectors_per_track * 512 bytes). Mas, como os HDDs modernos usam o registro de bits zonados e variam a densidade de área, não existe um "número de setores por trilha" fixo (ou conhecido). A típica especificação publicada de "63 setores por faixa" em unidades modernas é meramente uma conveniência numérica.

    

Answer 2

Não que dd não faça a tarefa, mas você pode considerar o uso de dd_rescue, se estiver disponível. isto fornece a capacidade de lidar melhor com qualquer setor corrompido e faz um trabalho melhor ao fornecer informações de status durante a cópia. A sintaxe é um pouco diferente:

# dd_rescue [options] infile outfile
# using a 1M block size allows dd_rescue to adjust it's reads/writes to the limits of the OS buffer 

dd_rescue -b 1M /dev/sda /dev/sdb

#sample of the status
dd_rescue: (info): Using softbs=1048576, hardbs=4096
dd_rescue: (info): ipos:   1048576000.0k, opos:   1048576000.0k, xferd:   1048576000.0k
               errs:      0, errxfer:         0.0k, succxfer:   1048576.0k
         +curr.rate:  107936kB/s, avg.rate:  107268kB/s, avg.load: 98.6%
         >-----------------------------------------< 100%  ETA:  0:00:00

Você pode achar que aumentar um pouco a velocidade do clone é menos importante do que ser informado sobre quanto tempo o processo está levando.

Esteja ciente de que a velocidade média inicial de transferência pode ser enganosa, já que os primeiros 50 GB ou mais de uma unidade de disco giratório são até 30% mais rápidos do que o restante. Ele copia das faixas fisicamente mais curtas no interior do disco e diminui à medida que as faixas ficam mais longas. Você não verá isso para SSDs, é claro.

    

Answer 3

bs significa que n b (bytes) são lidos e gravados a cada vez. Significa tamanho do bloco . bs não afeta necessariamente o tamanho do bloco de entrada ibs nem o tamanho do bloco de saída obs .

sync diz ao processo para esperar até que todos os dados tenham sido gravados corretamente no disco antes de passar para o próximo bloco . Geralmente, isso é melhor para garantir a integridade dos dados e evitar a perda de dados em caso de falta de energia (como desconectar a unidade da mesma forma que terminava de gravar dados), mas é mais lenta .

Sem sync , o processo de cópia é mais rápido e o dispositivo pode escrever mais rápido do que com sync habilitado, mas você pode perceber que quando as informações foram copiadas completamente, o disco ainda pode estar gravando informações seu cache para o suporte real. Isso geralmente é bom para discos rígidos ou quando você não planeja desconectar o dispositivo assim que a cópia é feita.

Coloque simplesmente:

• sync → espera que as informações sejam completamente escritas para suporte real.
• sem sync → enviar informações. ao dispositivo e deixe-o lidar com a gravação real.

Você pode acelerar o processo (um pouco) com a opção sync ativada usando um tamanho de bloco bs para evitar que acessem repetidamente o disco entre pequenas quantidades de tempo e, assim, tornando o processo geral mais lento.

Sempre usei dd sem a opção sync e nunca tive problemas. Aguarde as informações serem completamente escritas antes de ejetar qualquer dispositivo.