Existe uma maneira de determinar o valor ideal para o parâmetro bs para dd?

Question

Ocasionalmente, eu tenho visto comentários on-line ao longo das linhas de "certifique-se de definir 'bs =' porque o valor padrão demorará muito", e minhas próprias experiências extremamente não científicas de "bem que pareciam demorar mais do que na outra semana da semana passada "parecem confirmar isso. Então, sempre que eu uso 'dd' (normalmente no intervalo de 1-2GB), certifico-me de especificar o parâmetro de bytes. Cerca de metade do tempo eu uso o valor especificado em qualquer guia on-line do qual estou copiando; o resto do tempo eu escolho algum número que faz sentido a partir da listagem 'fdisk -l' para o que eu suponho ser a mídia mais lenta (por exemplo, o cartão SD que estou escrevendo).

Para uma determinada situação (tipo de mídia, tamanhos de barramento ou qualquer outra coisa importante), existe uma maneira de determinar um "melhor" valor? É fácil determinar? Se não, existe uma maneira fácil de obter 90-95% do caminho até lá? Ou é "basta escolher algo maior que 512", mesmo a resposta correta?

Eu mesmo pensei em experimentar o experimento, mas (além de ser muito trabalhoso) não sei quais fatores impactam a resposta, por isso não sei como criar um bom experimento.

    

Answer 1

dd data de quando era necessário traduzir antigas fitas de mainframe da IBM, e o tamanho do bloco tinha que corresponder ao usado para gravar a fita ou os blocos de dados seriam ignorados ou truncados. (As faixas de 9 faixas eram delicadas. Fique feliz por estarem mortas há muito tempo.) Atualmente, o tamanho do bloco deve ser um múltiplo do tamanho do setor do dispositivo (geralmente 4KB, mas em discos muito recentes pode ser muito maior e com um polegar muito pequeno drives podem ser menores, mas 4KB é um meio-termo razoável, independentemente) e quanto maior, melhor para o desempenho. Costumo usar tamanhos de bloco de 1 MB com discos rígidos. (Temos muito mais memória para jogar nesses dias também.)

    

Answer 2

Há apenas uma maneira de determinar o tamanho ideal de bloco, e isso é uma referência. Acabei de fazer um benchmark rápido. A máquina de teste é um PC rodando Debian GNU / Linux, com kernel 2.6.32 e coreutils 8.5. Ambos os sistemas de arquivos envolvidos são ext3 em volumes LVM em uma partição de disco rígido. O arquivo de origem é de 2 GB (2040000kB para ser preciso). O armazenamento em cache e o armazenamento em buffer estão ativados. Antes de cada execução, esvaziei o cache com sync; echo 1 >|/proc/sys/vm/drop_caches . Os tempos de execução não incluem um final sync para liberar os buffers; o final sync leva na ordem de 1 segundo. As same runs foram cópias no mesmo sistema de arquivos; as diff runs foram copiadas para um sistema de arquivos em um disco rígido diferente. Para consistência, os tempos relatados são os tempos de relógio de parede obtidos com a utilidade time , em segundos. Eu só executei cada comando uma vez, então não sei quanta variação há no momento.

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Conclusão: um tamanho de bloco grande (vários megabytes) ajuda, mas não dramaticamente (muito menos do que eu esperava para cópias com mesmo drive). E cat e cp não funcionam tão mal. Com esses números, não acho que dd vale a pena se incomodar. Vá com cat !

    

Answer 3

Concordo com o geekossauro que o tamanho deve ser um múltiplo do tamanho do bloco, que geralmente é de 4K.

Se você quiser encontrar o tamanho de bloco stat -c "%o" filename é provavelmente a opção mais fácil.

Mas diga que você faz dd bs=4K , isso significa que read(4096); write(4096); read(4096); write(4096) ...

Cada chamada de sistema envolve uma alternância de contexto, que envolve alguma sobrecarga e, dependendo do agendador de E / S, as leituras com gravações intercaladas podem fazer com que o disco faça muitas pesquisas. (Provavelmente não é um grande problema com o planejador do Linux, mas ainda assim algo em que pensar.)

Então, se você fizer bs=8K , você permite que o disco leia dois blocos por vez, que provavelmente estão juntos no disco, antes de procurar outro lugar para fazer a gravação (ou para I / O de serviço para outro processo ).

Por essa lógica, bs=16K é ainda melhor, etc.

Então, o que eu gostaria de saber é se existe um limite superior em que o desempenho começa a piorar ou se é limitado pela memória.

    

Answer 4

Como diz Gilles, você pode determinar o parâmetro ideal para a opção bs para dd por referência. Isso, no entanto, levanta a questão: como você pode convenientemente comparar esse parâmetro?

Minha tentativa de resposta a essa pergunta é: use dd-opt , o utilitário em que comecei recentemente a trabalhar resolver precisamente este problema:)

    

Answer 5

Eu otimizei para o leitor de sdcard usb2.0 que parece rodar melhor em bs=10M . Eu tentou 4k, em até 16M, após 8-10M sem melhora. Você pode ver como a medição da taxa de transferência se degrada ... provavelmente devido ao carregamento dos buffers no dispositivo, em seguida, aguardando que o dispositivo seja transferido para o meio real.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s