Quando as configurações bs e count são erradas para dd?

Question

(Por mal eu quero dizer "vai quebrar as coisas".)

Suponha que estamos prestes a usar dd . Escolhemos um conjunto válido de if , of e possivelmente seek e skip . Nós cuidadosamente garantimos que o comando não irá escrever além da nossa região de saída pretendida.

Como podemos agora sutilmente quebrar as coisas escolhendo uma combinação ruim de bs e count ? Como saberíamos?

A razão pela qual eu pergunto é que parece haver valores preferenciais mágicos que aparecem. Por exemplo, nesta pergunta sobre como gerar um arquivo 1G aleatório, as duas primeiras respostas usam if=/dev/urandom , of=sample.txt , bs=64M e count=16 .

Como crio um arquivo aleatório de 1 GB no Linux?

É claro que essas não são as únicas configurações válidas, mas ambas as respostas usaram essas configurações, sugerindo que essa escolha é particularmente boa e razoável. Especialmente em um caso como este, onde não há sistema de arquivos ou mesmo disco físico, não está claro para mim se a escolha de configurações pode estar errada - não apenas ineficiente, mas errada . Meu palpite é que dd deve escrever um número inteiro de blocos por vez, assim como bs aumenta, assim como o uso de memória e esses valores afetam apenas o desempenho.

O exemplo é apenas um exemplo e não algo com o qual estou especificamente preocupado, então vá em frente e resolva casos em que o que está sendo copiado tem um sistema de arquivos.

Usar o dd é sempre um salto assustador de fé para mim.

    

Answer 1

Ajuda! dd é assustador!

Você não está sozinho. De dicas para o Linux :

The ' dd ' command is one of the original Unix utilities and should be in everyone's tool box... Some people believe dd means "Destroy Disk" or "Delete Data" because if it is misused, a partition or output file can be trashed very quickly. Since dd is the tool used to write disk headers, boot records, and similar system data areas, misuse of dd has probably trashed many hard disks and file systems.

Mas não se preocupe. Uma vez que você saiba de suas complexidades, você estará invocando dd com a graça calma de um cowboy de rodeio.

Será que vai quebrar? O que é isso count ing bs ?

Vamos lidar primeiro com a primeira pergunta.

How can we now subtly break things by choosing a bad combination of bs and count? How would we know?

Se você quer dizer 'conseqüências não intencionais' por 'quebrar', então apenas especificando-as, em teoria. O que quero dizer com isso? Bem, digamos que você queira copiar image.img em um cartão SD localizado em /dev/sdc . Então você combina os parâmetros em seu exemplo:

# dd if=/home/someone/image.img of=/dev/sdc bs=64M count=16

Deve ser bom reutilizar essas configurações, certo? Vamos apenas esperar que dd termine ... agora, o que está dizendo?

16+0 records in
16+0 records out
1073741824 bytes (1.1 GB) copied, 34.1303 s, 31.5 MB/s

Apenas 1,1 GB copiados! Mas image.img é 2GB ou mais, eu quero a coisa toda copiada! Dizendo dd para copiar 16 lotes de 64M (onde M = 1024 * 1024, aliás) você especificou um tamanho. Você saberia pela saída de status. Se você quiser copiar o arquivo inteiro, combine o tamanho com bs e count ; ou apenas omitir esses completamente:

# dd if=/home/someone/image.img of=/dev/sdc
4364864+0 records in
4364864+0 records out
2234810368 bytes (2.2 GB) copied, 45.9502 s, 48.6 MB/s

O que acontece se ficarmos realmente impertinentes e dissermos ao dd para copiar mais dados do que os disponíveis?

# dd if=/home/someone/image.img of=/dev/sdc bs=1M count=4096
2131+1 records in
2131+1 records out
2234810368 bytes (2.2 GB) copied, 77.9768 s, 28.7 MB/s

Ah, dd apenas copia quantos bytes ele recebe. Isso é útil.

Monitorando dd

Falando de saída de status, dd (variante GNU) respeita e responde ao sinal INFO SIGUSR1 :

# echo "In another terminal or TTY"
# pkill -USR1 -n -x dd
# echo "Printed to stdout on the terminal/tty running dd:"
534+0 records in
534+0 records out
559939584 bytes (560 MB) copied, 1.68414 s, 332 MB/s

Prático para manter um olho em uma transferência que é lenta ou que você espera pendurar por algum motivo. Pares bem com watch , mas certifique-se de dar watch um tempo de intervalo razoavelmente longo.

O dd tem outras opções que eu deva conhecer?

dd tem outras opções, mas na maioria dos casos, se você precisar usá-las, saberá o que elas fazem. Ainda assim, alguns exemplos podem dar uma ideia:

• conv=CONVS : converta a entrada de acordo com uma ou mais opções de conversão
• seek=N e skip=N : ignore blocos [obs | ibs] no início de [output | input]
• status=X : (suprime a saída) noxfer ou none

Estou me sentindo muito melhor com dd agora!

Ótimo! Em pouco tempo, você enviará uma imagem inicializável pela Internet para ser gravada diretamente em um cartão microSD usando uma combinação de dd e ssh .

Mas o que significa o acrônimo dd ?

Uma boa última pergunta. Para essa pergunta e outras semelhantes, encaminharei você para a entrada do arquivo de jargão por dd .

Sinta-se encorajado a pedir esclarecimentos se algo for mais opaco do que deveria ser!

    

Answer 2

Sua pergunta é autocontraditória:

We've carefully ensured that the command will not write past our intended output region.

How can we now subtly break things by choosing a bad combination of bs and count? How would we know?

Se você escolheu uma combinação ruim de bs e count , a única coisa que você pode quebrar é escrever além da região de saída desejada (ou não alcançá-la, o que considero o mesmo problema)

Se você tiver cuidadosamente assegurado que o comando não irá escrever além da região de saída pretendida, não será possível quebrar as coisas, pois você já garantiu que a combinação de bs e count não seja ruim. Os dois não podem ocorrer simultaneamente. Da mesma forma, se você não entendeu os parâmetros bs e count , não é possível garantir com cuidado que sua região de saída esteja correta.

Dito isso, o parâmetro bs é amplamente um parâmetro de ajuste de desempenho. Se você especificar um bs menor que o tamanho físico do setor e você está lendo / escrevendo no modo raw, ou outro valor completamente fora do whack, dd será simplesmente, e não em um maneira sutil ('Abort: I / O error!'). Caso contrário, as coisas serão apenas lentas.