Por que o dd leva muito tempo?

Question

Eu preciso copiar um disco para outro. Eu tentei com o comando abaixo e demora quase um dia para copiar 1 TB de disco.

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

Eu tentei o mesmo em um sistema Unix com o comando abaixo e ele conclui dentro de algumas horas

dd if=/dev/sda of=/dev/rdsk

Qual é a alternativa que eu poderia usar para copiar de disco para disco mais rápido?

    

Answer 1

dd tem muitas opções (estranhas), consulte dd (1) .

Você deve declarar explicitamente o tamanho do buffer, então tente

dd if=/dev/sda of=/dev/sdb bs=16M

IIRC, o tamanho do buffer padrão é de apenas 512 bytes. O comando acima define para 16 megabytes. Você poderia tentar algo menor (por exemplo, bs=1M ), mas você deve usar mais do que o padrão (especialmente em hardware de disco recente com setores de 4Kbytes, ou seja, Formato Avançado ). Eu ingenuamente recomendo algum poder de dois que seja pelo menos um megabyte.

Com o tamanho padrão do buffer de 512 bytes, eu acho (mas eu posso estar muito errado) que o hardware requer que o kernel transfira 4K para cada bloco de 512 bytes.

Em relação a rdsk , as páginas man sd (4) dizem:

At this time, only block devices are provided. Raw devices have not yet been implemented.

O aumento do tamanho do buffer do dd proporcionará mais desempenho para as operações de leitura e gravação. Agora todos os discos têm buffer de leitura / gravação de hardware. Mas se você aumentar o tamanho do buffer de dd mais do que o buffer de hardware, seu desempenho diminuirá, pois o dd lerá do primeiro disco para o buffer quando o segundo disco tiver escrito tudo a partir de seu próprio buffer de hardware. Você precisa definir a opção bs do comando dd a cada vez um valor diferente para diferentes dispositivos.

    

Answer 2

Anos atrás no Unix-land dd era a maneira necessária para copiar um dispositivo de bloco. Isso foi levado adiante como conhecimento de carga, embora (em sistemas baseados em Linux, pelo menos) cat seja quase sempre mais rápido que dd .

No entanto, mesmo de volta ao histórico, um tamanho de bloco decente ajudou a reduzir o número de chamadas de sistema (lentas), dado que cada chamada de sistema acionava uma operação de E / S. O tamanho padrão do bloco é de 512 bytes (um setor de disco). A coleta de vários blocos de disco juntos em uma única leitura era - e também é - aceitável. Este exemplo usa um tamanho de bloco de 32 MB:

dd bs=$((512*2048*32)) if=/dev/source of=/dev/target

Nos sistemas atuais baseados em Linux, porém, os discos podem ser copiados com mais eficiência com um simples cat

cat /dev/source >/dev/target

(Como observado nos comentários sobre sua pergunta pv pode ser substituído por cat e lhe dará uma indicação de progresso e taxa de transferência).

    

Answer 3

Muito boa pergunta. A interface bruta é implementada em alguns sistemas unix (tru64, hpux, solaris) mas não no linux. A interface bruta torna a transferência mais rápida porque a E / S do Unix é ignorada. A interface do bloco ( /dev/dsk ou /dev/disk ) é mais lenta porque usa o sistema de E / S do Unix. Para acelerar dd (gnu dd can) use bs=30M ou bs=20M dependendo do seu hw. A resposta curta é: NÃO, não é implementado, pelo menos tanto quanto eu sei. Estou usando o linux desde os tempos antigos do kernel versão 2.2 e nunca vi rdsk usado no unix.

    

Answer 4

Geralmente, dd pode ser evitado em favor de algumas alternativas. Existem várias boas razões para usar o GNU ddrescue . No Ubuntu, você pode instalá-lo com:

sudo apt-get install gddrescue

e simplesmente ddrescue para usar. Note que diferentemente do nome do pacote, o executável não tem o% inicial% co_de.

Utilizar é tão simples como:

ddrescue inputFile outputFile logFile

O arquivo de log (denominado o que você escolher) permite pausar / parar e reiniciar, sem refazer o trabalho anterior, o que é útil ao fazer grandes clones ou recuperar discos. Por padrão, ele exibe o progresso, a velocidade de cópia atual, a velocidade média de cópia e o número de blocos defeituosos encontrados.

Ele usa padrões sensíveis para tamanho de bloco, então a velocidade de cópia é sempre tão rápida quanto o dispositivo pode suportar, na minha experiência, pelo menos (eu clonei muitas centenas de unidades com ele, todos os tamanhos e tipos).

Freqüentemente, os inversores que estão começando a falhar têm problemas de velocidade, como patches ocasionais de lentidão, velocidade média baixa, pausas longas e repentinas (setores defeituosos) ou redefinições completas (erros graves de superfície). g pode ajudá-lo a identificar todos os itens acima e reiniciar seu clone (desde que você tenha especificado um arquivo de log), mesmo que sua unidade esteja sendo redefinida automaticamente.