Por que especificar o tamanho do bloco ao copiar dispositivos de tamanho finito?

Question

Em tutoriais on-line, muitas vezes é sugerido usar o seguinte comando para copiar um CDROM para uma imagem iso:

$ dd if=/dev/dvd of=foobar.iso bs=2048

Por que o tamanho do byte deve ser especificado? Percebo que, de fato, 2048 é o tamanho padrão de bytes para imagens de CD-ROM , mas parece que dd sem Especificar bs= ou count= também funciona.

Em que circunstâncias seria problemático não especificar bs= ou count= ao copiar de um dispositivo de tamanho finito?

    

Answer 1

Quando o dd é adequado para copiar dados? (ou, quando são lidas () e escritas () parciais) aponta uma ressalva importante ao usar count : dd pode copiar blocos parciais, então quando dado count ele irá parar após o número dado de blocos, mesmo que alguns dos blocos estivessem incompletos. Você pode, portanto, acabar com menos de bs * count bytes copiados, a menos que você especifique iflag=fullblock .

O tamanho de bloco padrão para dd é de 512 bytes. count é um limite; Como sua pergunta sugere, não é necessário copiar um dispositivo de tamanho finito e, na verdade, destina-se a copiar apenas parte de um dispositivo.

Acho que há dois aspectos a serem considerados aqui: desempenho e recuperação de dados.

No que diz respeito ao desempenho, você deseja idealmente que o tamanho do bloco seja pelo menos igual a, e um múltiplo, do tamanho do bloco físico subjacente (portanto, 2048 bytes ao ler um CD-ROM). Na verdade, hoje em dia você pode também especificar tamanhos de bloco maiores para dar aos sistemas de cache subjacentes uma chance de armazenar em buffer as coisas para você. Porém, aumentar o tamanho do bloco significa que dd precisa usar muito mais memória, e pode ser contraproducente se você estiver copiando em uma rede devido à fragmentação de pacotes.

No que diz respeito à recuperação de dados, você pode recuperar mais dados de um disco rígido com falha se usar tamanhos de bloco menores; isto é o que programas como dd-rescue fazem automaticamente: eles lêem blocos grandes inicialmente, mas se um bloco falhar, eles o relêem com tamanhos de bloco menores. dd não fará isso, apenas falhará no bloco inteiro.

    

Answer 2

Alterar o tamanho do bloco é uma boa maneira de alterar o quanto fica armazenado em buffer ou lido / gravado por vez.

Não se relaciona realmente com se é um dispositivo de bloco real ou um dispositivo infinito / virtual. É sobre o quanto você deseja armazenar na memória antes de dd escrever. bs= define ibs= (quantos dados são lidos de cada vez) e obs= (quantos dados são gravados de cada vez). Quanto mais alto for o obs= , mais iterações de ibs= serão necessárias antes que você tenha dados suficientes para que dd comece a gravar no destino.

count= também não depende de outra coisa senão do que você deseja fazer. Ele controla quantos "blocos" (medidos por ibs= ) serão necessários para que dd considere seu trabalho como sendo feito.

    

Answer 3

Há um pouco de culto de carga em torno de dd . Originalmente, havia dois bugs em cp que causavam problemas: ele detectaria arquivos como escasso quando relatado com um tamanho de bloco diferente de 512 (o Linux usava um tamanho de bloco de 1024) e não limpava blocos vazios do destino quando copiando de um arquivo esparso para um dispositivo de bloco.

Você pode encontrar algumas referências a isso no primeiros arquivos da lista de discussão do Linux .

Então as pessoas se acostumaram a dd ser a maneira correta de lidar com imagens de disco, e cp caiu no esquecimento. E como o dd usa um tamanho de bloco padrão de 512, ele é lento (mais lento que o cp nos sistemas modernos). Mas não é óbvio que tamanho de bloco você deve usar. Provavelmente, no seu caso, alguém leu que 2048 é o tamanho de bloco "natural" de um CD-ROM (isto é, os CD-ROMs são divididos em 2.352 setores de bytes contendo 2.048 bytes de dados, juntamente com informações de correção de erros) e decidiu que é o tamanho "certo" para usar com o dd, quando na verdade você provavelmente obteria resultados mais rápidos se usasse um tamanho de bloco (moderadamente) maior. Na verdade, o GNU cp usa um tamanho de bloco padrão de 64k por esse motivo.

tl; dr: cp /dev/dvd foobar.iso deve funcionar bem. O tamanho de bloco padrão para dd é 512. O único efeito que se deixa sozinho na maioria das circunstâncias modernas é tornar o processo de cópia mais lento.

    

Answer 4

Usar a opção blocksize em dd especifica efetivamente quantos dados serão copiados para a memória a partir do subsistema de E / S de entrada antes de tentar gravar no subsistema de E / S de saída. A saída é a mesma (como todo o disco está sendo copiado), os pedaços estão sendo lidos apenas no tamanho diferente que você especificar (a maioria das implementações dd vem com um tamanho padrão de 512 bytes).

Se você tiver grandes quantidades de memória sobressalente e aumentar o tamanho dos blocos, mais blocos de dados maiores poderão ser lidos em sucessão, armazenados em buffer e liberados para o destino de saída. Um tamanho de bloco menor requer mais sobrecarga em termos de cada indivíduo lseek, memset etc.

Sua milhagem pode variar dependendo de onde seus if= e of= estão definidos, e qual hardware você está passando, se você tem pouca memória e assim por diante.

    

Answer 5

O bs = representa o tamanho do bloco para ler ou escrever. Deixar o campo intacto ou não especificá-lo pode parecer fazer o mesmo trabalho de copiar, mas há um fato oculto em usá-lo. Por exemplo,

• Tendo 1000000000000000 arquivos com apenas 1 ~ 10 kb.
• Ter um único arquivo para 10 gb

No primeiro caso, foi descoberto que o tamanho de bloco inferior aumenta a velocidade de cópia. Enquanto no último, o tamanho de bloco superior tem sido uma opção melhor, pois aumenta o tamanho do setor deixando um menor número de sector change de comando, o que geralmente resulta em operações de I / O mais rápidas.