Por que o dd lê o dispositivo de saída?

2

Enquanto dd uma imagem de DVD do CentOS 7 x86_64 para uma unidade USB (sdb), eu monitorei o progresso com iostat .

Mantinha a alternância entre a maioria das gravações no pen drive:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              18,00       380,00        28,00        380         28
sdb              79,00        16,00      9000,00         16       9000

E lendo a partir dele o disco rígido e a unidade USB simultaneamente:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              53,00      5180,00         0,00       5180          0
sdb            1329,00      5316,00         0,00       5316          0

Não havia mais nada acontecendo na máquina e, quando dd parou, os discos ficaram inativos.

É algum tipo de processo de soma de verificação interna em dd ?

Algo inerente aos drivers das unidades USB no Linux 3.16.0?

    
por Giovanni Tirloni 02.12.2014 / 22:24

1 resposta

1

Encontrei uma situação semelhante ao limpar com segurança um disco rígido externo (USB 2.0): longos períodos de leitura seguidos por alguns segundos de gravações de alto rendimento, quando esperava gravações de 100%. Eu usei pv para me mostrar uma velocidade geral de gravação (veja o comando abaixo) e eu estava recebendo uma média de 10MB / s, em rajadas de 14MB / s por ~ 10 segundos seguidos por alguns kB / s. Minha saída iostat se parecia muito com a sua.

Descobri que o problema era meu tamanho de bloco dd muito pequeno (512 bytes). Eu suspeito que o que está acontecendo é que o kernel estava lendo blocos em seus buffers de 1k por bloco, de forma que o dd possa sobrescrever 512 bytes por vez, o que é liberado. Eu não sou um especialista em kernel, então é só um palpite.

Eu posso dizer que bombeando meu tamanho de bloco dd para 72K fez uma grande diferença . Agora estou vendo > 40MB / s de gravações sustentadas. Isso é muito próximo do máximo teórico que o USB 2.0 pode fornecer (480Kb / s, sem contar a sobrecarga USB) e também muito próximo da velocidade máxima de gravação sustentada que esse disco de 10 anos pode atingir (algo como 55MB / s). Estou satisfeito que esta é mais ou menos velocidade bare-metal.

Aqui está o comando que estou usando para limpar a unidade:

openssl enc -aes-256-ctr -pass \
pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
-nosalt </dev/zero \
| pv -bartpes 160041885696 -B 128K \
| dd bs=72K count=2170707 of=/dev/sdf iflag=fullblock

Linhas 1-3 pipe / dev / zero pela criptografia AES-256-CTR, usando uma senha gerada a partir de / dev / urandom. Então, é um fluxo de lixo criptograficamente aleatório.

A linha 4 mostra o progresso, dada a contagem de bytes do drive de 160GB e usando um tamanho de buffer de transferência em pv de 128KiB.

A linha 5 usa um tamanho de bloco que escolhi usando uma calculadora, tentando encontrar o maior múltiplo de 512 que era um fator do total de # bytes da unidade. iflag = fullblock faz o dd ler repetidamente em seu buffer até que ele tenha 1 bloco inteiro antes de gravar.

    
por 30.11.2015 / 05:52

Tags