É melhor usar cat, dd, pv ou outro procedimento para copiar um CD / DVD?

fundo

Estou copiando alguns CDs / DVDs de dados para arquivos ISO para usá-los mais tarde, sem a necessidade deles na unidade.

Estou procurando na Net por procedimentos e encontrei muito:

• Uso de catpara copiar um meio: http://www.yolinux.com/TUTORIALS/LinuxTutorialCDBurn.html

  cat /dev/sr0 > image.iso
  

• Use ddpara fazer isso (aparentemente o mais utilizado): http://www.linuxjournal.com/content/archiving-cds-iso-commandline

  dd if=/dev/cdrom bs=blocksize count=count of=/path/to/isoimage.iso
  

• Use apenas pvpara fazer isso: Veja man pvpara obter mais informações, embora aqui esteja um trecho:

  Taking an image of a disk, skipping errors:
        pv -EE /dev/sda > disk-image.img
  
  Writing an image back to a disk:
        pv disk-image.img > /dev/sda
  
  Zeroing a disk:
        pv < /dev/zero > /dev/sda
  

Não sei se todos devem ser equivalentes, embora tenha testado alguns deles (usando a md5sumferramenta) e, pelo menos, dde nãopv sejam equivalentes. Aqui estão os arquivos gerados e da unidade usando cada procedimento:md5sum

md5 do procedimento dd: 71b676875b0194495060b38f35237c3c

MD5 do procedimento PV: f3524d81fdeeef962b01e1d86e6acc04

EDIT: Essa saída foi de outro CD que a saída fornecida. De fato, eu percebi que existem alguns fatos interessantes que eu forneço como resposta.

De fato, o tamanho de cada arquivo é diferente em comparação.

Portanto, existe um melhor procedimento para copiar um CD / DVD ou estou apenas usando os comandos incorretamente?

Mais informações sobre a situação

Aqui estão mais informações sobre o caso de teste que estou usando para verificar os procedimentos que encontrei até agora:

isoinfo -d i /dev/sr0 Saída: https://gist.github.com/JBFWP286/7f50f069dc5d1593ba62#file-isoinfo-output-19-aug-2015

ddpara copiar os meios de comunicação, com somas de verificação de saída e saída de informações do arquivo: https://gist.github.com/JBFWP286/75decda0a67605590d32#file-dd-output-with-md5-and-sha256-19-aug-2015

pvpara copiar os meios de comunicação, com somas de verificação de saída e saída de informações do arquivo: https://gist.github.com/JBFWP286/700a13fe0a2f06ce5e7a#file-pv-output-with-md5-and-sha256-19-aug-2015

Qualquer ajuda será apreciada!

Todos os seguintes comandos são equivalentes. Eles lêem os bytes do CD /dev/sr0e os gravam em um arquivo chamado image.iso.

cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image.iso

Por que você usaria um sobre o outro?

• Simplicidade. Por exemplo, se você já conhece catou cpnão precisa aprender outro comando.

• Robustez. Este é um pouco de uma variante da simplicidade. Qual é o risco de mudar o comando para mudar o que ele faz? Vamos ver alguns exemplos:

  • Qualquer coisa com redirecionamento: você pode acidentalmente colocar um redirecionamento na direção errada ou esquecê-lo. Como o destino deveria ser um arquivo inexistente, set -o noclobberverifique se você não substituiu nada; no entanto, você pode substituir um dispositivo se escrever acidentalmente >/dev/sda(para um CD, que é somente leitura, não há riscos, é claro). Isso fala em favor de cat /dev/sr0 >image.iso(é difícil errar de uma maneira prejudicial) sobre alternativas como tee </dev/sr0 >image.iso(se você inverter os redirecionamentos ou esquecer a entrada na qual a entrada teeserá gravada /dev/sr0).
  • cat: você pode acidentalmente concatenar dois arquivos. Isso deixa os dados facilmente recuperáveis.
  • dd: ie oestão perto do teclado, e um pouco incomum. Não há equivalente noclobber, of=substituirá felizmente qualquer coisa. A sintaxe de redirecionamento é menos suscetível a erros.
  • cp: se você trocar acidentalmente a fonte e o destino, o dispositivo será substituído (novamente, assumindo um dispositivo não somente leitura). Se cpfor chamado com algumas opções como -Rou -aque algumas pessoas adicionam por meio de um alias, ele copiará o nó do dispositivo em vez do conteúdo do dispositivo.

• Funcionalidade adicional. A única ferramenta aqui que possui funcionalidade adicional útil é pv, com suas poderosas opções de relatório.
  Mas aqui você pode verificar quanto foi copiado observando o tamanho do arquivo de saída de qualquer maneira.

• Atuação. Este é um processo vinculado à E / S; a principal influência no desempenho é o tamanho do buffer: a ferramenta lê um pedaço da fonte, grava o pedaço no destino, repete. Se o pedaço for muito pequeno, o computador gasta seu tempo alternando entre tarefas. Se o pedaço for muito grande, as operações de leitura e gravação não poderão ser paralelas. O tamanho ideal do pedaço em um PC é tipicamente de alguns megabytes, mas obviamente depende muito do sistema operacional, do hardware e do que mais o computador está fazendo. Fiz benchmarks de cópias de disco rígido para disco rígido há um tempo atrás, no Linux, que mostrou que para cópias dentro do mesmo disco, dd com um tamanho de buffer grande, tem a vantagem, mas para cópias em disco cruzado, catconquistou qualquer ddtamanho de buffer.

Existem algumas razões pelas quais você é ddmencionado com tanta frequência. Além do desempenho, eles não são razões particularmente boas.

• Em sistemas Unix muito antigos, algumas ferramentas de processamento de texto não podiam lidar com dados binários (usavam seqüências terminadas em nulo internamente, por isso tendiam a ter problemas com bytes nulos; algumas ferramentas também supunham que os caracteres usavam apenas 7 bits e não processar conjuntos de caracteres de 8 bits corretamente). Eu não tenho certeza se isso nunca foi um problema com cat(ele estava com mais ferramentas orientada a linha como head, sed, etc.), mas as pessoas tendem a evitá-lo em dados binários por causa de sua associação com o processamento de texto. Isso não é um problema em sistemas modernos, como Linux, OSX, * BSD ou qualquer coisa que seja compatível com POSIX.
• Há um tipo de mito que ddé um pouco "de nível inferior" do que outras ferramentas como cate acessa dispositivos diretamente. Isto é completamente falso: dde cate teee os outros todos leitura bytes a partir de sua entrada e escrever os bytes para a sua saída. A verdadeira magia está em /dev/sr0.
• ddpossui uma sintaxe de linha de comando incomum, portanto, explicar como funciona dá mais uma oportunidade de brilhar, explicando algo que acabou de ser escrito cat /dev/sr0.
• Usar dd com um tamanho de buffer grande pode ter um desempenho melhor, mas nem sempre é o caso (consulte alguns benchmarks no Linux ).

Um grande risco ddé que ele pode ignorar silenciosamente alguns dados . Eu acho que ddé seguro enquanto skipou countnão for aprovado, mas não tenho certeza se esse é o caso em todas as plataformas. Mas não tem vantagem, exceto pelo desempenho.

Portanto, basta usar pvse você quiser um relatório de progresso sofisticado ou catse não quiser.

Existem fatos interessantes neste caso, especialmente os seguintes:

• Acabei de verificar a saída que obtive e forneci (usei outro disco exatamente desta vez, o disco de instalação do Xubuntu 15.04 x64) e, com os dois procedimentos ( dde pv), as somas de verificação são idênticas .
• Tive a ideia de, após executar o ddprocedimento, abrir a unidade e fechá-la com o mesmo disco e, em seguida, terminar o teste com o pvprocedimento. Fazendo exatamente isso, obtive cópias idênticas nos dois procedimentos.
• Eu acho que eu tenho diferentes somas de verificação pela primeira vez, porque, por algum motivo, os dados recolhidos a partir da unidade de CD / DVD parece ser "gravada" para outros fins por algum tempo (como um cache) - assim, outras operações como somas de verificação foram feito muito mais rápido que a transferência. Comente se você sabe a causa exata disso.
• Outro fato é que ddsem o count=Xparâmetro para corretamente no final do disco e fornece a mesma imagem de disco que pv(as somas de verificação são idênticas), por isso é melhor eu usar ddparâmetros sem ou apenas pv.

Então, por enquanto, parece pve ddpode conseguir uma cópia em CD / DVD com os mesmos resultados.