Por que 'dd' produz arquivos diferentes para o mesmo pen drive?

Acabei de salvar a restauração do Windows 8.1 em um pendrive; agora, eu tenho criado a cópia de baixo nível dela no meu disco rígido, executando o seguinte comando:

sudo dd se = / dev / sdf de = / disk2 / Archive / windows8.1-restore.img bs = 4M oflag = direct

Eu queria checar se meu comando 'dd' estava ok, então eu o executei novamente duas vezes, especificando ambos bs=8Me bs=16M; Eu verifiquei o tamanho e é exatamente o mesmo, mas o md5sum fornece uma saída diferente para os três arquivos:

c38a2b07b3d473d3f1876331edc2647b windows8.1-restore.img.4M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-restore.img.8M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-restore.img.16M

Acredito ter desmontado o pen drive pela segunda e terceira vez.

Eu deveria estar preocupado com alguma coisa?

editar

O tamanho total do arquivo é 31024349184bytes em todos os casos, pelo que entendi bs=xxxé apenas controlar a velocidade, caso alguém queira despejar todo o dispositivo / unidade USB.

— Emanuele
fonte

Foi o pau desmontado quando executou ddcom bs=4M?

— gronostaj

Não. Eu acho que deveria, certo?

— Emanuele

Certo, você deve desmontá-lo. (Ou talvez montado somente leitura.) Também não tenho certeza de onde você está obtendo o tamanho dos blocos. Eu usaria bs = 512. Eu quase sempre uso bs = 512, exceto ao usar uma unidade de CD, porque eles podem querer um tamanho de bloco diferente (como bs = 2048, ou talvez bs = 2352 ou qualquer tamanho de bloco que esteja sendo usado, como observado por <A HREF = " osta .org / technology / cdqa7.htm "> tamanhos de blocos de CD </A>).

— TOOGAM

@TOOGAM Veja como criar links .

— gronostaj

@Emanuele Eu não acho que você esteja errado. ddSabe-se que tamanhos pequenos de blocos diminuem o desempenho, porque força muito mais chamadas de leitura e gravação do que seria necessário. Acredito que o gronostaj esteja correto, seu problema é que você ddd o disco com o sistema de arquivos montado. Supondo que você não tenha remontado o sistema de arquivos desde então, poderá verificar isso reexecutando seu comando dd inicial; você também verá um MD5sum idêntico a essa chamada.

— a CVn 01/02

A gravação de pequenas quantidades de dados em uma unidade é lenta; portanto, os buffers do sistema gravam para confirmar todos eles de uma vez mais tarde. Quando o buffer contém dados suficientes para uma operação de gravação eficiente ou quando algum processo usa a syncchamada do sistema , o buffer é liberado para o dispositivo.

ddexecuta uma cópia de baixo nível, ou seja. ele lê dados fisicamente presentes em um dispositivo. Não leva em consideração os buffers.

Se a unidade foi montada quando você executou dd bs=4M, é possível que algumas gravações já tenham sido armazenadas em buffer, mas não confirmadas. Você despejou a unidade sem alterações no buffer.

umountchamadas syncinternamente para garantir a integridade dos dados. Os dispositivos desmontados geralmente não são acessados, a menos que você solicite explicitamente algum processo para fazê-lo, portanto, é improvável que a unidade mude após a desmontagem.

Depois, você executou ddduas vezes na unidade sem montá-la no meio. É por isso que bs=8Me as bs=16Mchamadas produziram os mesmos resultados.

A unidade foi modificada entre bs=4Me bs=8Mchamadas, no entanto, portanto, o primeiro despejo é diferente. bs=não importava, ligar umountfazia.

Você deve sempre desmontar o dispositivo antes de usá dd-lo, caso contrário, outro processo poderá modificar seu conteúdo enquanto ddestiver realizando seu trabalho e prejudicar a integridade do arquivo.

— gronostaj
fonte

Eu pensei que tinha sido um pouco idiota por tê-lo montado da primeira vez quando eu o executei dd. Acho que vou manter o arquivo tirado com o dispositivo desmontado . Assustador!

— Emanuele