È meglio usare cat, dd, pv o un'altra procedura per copiare un CD / DVD?

sfondo

Sto copiando alcuni CD / DVD di dati in file ISO per usarli in seguito senza averne bisogno nell'unità.

Sto cercando sulla rete le procedure e ho trovato molto:

• Uso di catper copiare un supporto: http://www.yolinux.com/TUTORIALS/LinuxTutorialCDBurn.html

  cat /dev/sr0 > image.iso
  

• Uso di ddfarlo (apparentemente il più usato): http://www.linuxjournal.com/content/archiving-cds-iso-commandline

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

• Utilizzare solo pvper ottenere questo risultato: vedere man pvper ulteriori informazioni, anche se ecco un estratto di esso:

  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
  

Non so se tutti dovrebbero essere equivalenti, anche se ne ho provato alcuni (usando lo md5sumstrumento) e, almeno, dde nonpv sono equivalenti. Ecco il file sia dell'unità che dei file generati usando ciascuna procedura:md5sum

md5 della procedura dd: 71b676875b0194495060b38f35237c3c

md5 della procedura pv: f3524d81fdeeef962b01e1d86e6acc04

EDIT: quell'output proveniva da un altro CD rispetto all'output fornito. In effetti, ho capito che ci sono alcuni fatti interessanti che fornisco come risposta.

In effetti, la dimensione di ciascun file è diversa rispetto all'altra.

Quindi, esiste una procedura migliore per copiare un CD / DVD o sto semplicemente usando i comandi in modo errato?

Maggiori informazioni sulla situazione

Ecco ulteriori informazioni sul test case che sto usando per verificare le procedure che ho trovato finora:

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

ddper copiare il supporto, con checksum di output e informazioni sui file Output: https://gist.github.com/JBFWP286/75decda0a67605590d32#file-dd-output-with-md5-and-sha256-19-aug-2015

pvper copiare il supporto, con checksum di output e informazioni sui file Output: https://gist.github.com/JBFWP286/700a13fe0a2f06ce5e7a#file-pv-output-with-md5-and-sha256-19-aug-2015

Qualsiasi aiuto sarà apprezzato!

Tutti i seguenti comandi sono equivalenti. Leggono i byte del CD /dev/sr0e li scrivono in un file chiamato 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

Perché dovresti usarne uno sopra l'altro?

• Semplicità. Ad esempio, se già conosci cato cpnon hai bisogno di imparare ancora un altro comando.

• Robustezza. Questa è una variante della semplicità. Quanto rischio c'è che cambiare il comando cambierà ciò che fa? Vediamo alcuni esempi:

  • Qualsiasi cosa con il reindirizzamento: potresti accidentalmente mettere un reindirizzamento nella direzione sbagliata o dimenticarlo. Poiché la destinazione dovrebbe essere un file inesistente, è set -o noclobbernecessario assicurarsi di non sovrascrivere nulla; tuttavia potresti sovrascrivere un dispositivo se scrivi accidentalmente >/dev/sda(per un CD, che è di sola lettura, ovviamente non c'è rischio). Questo parla a favore di cat /dev/sr0 >image.iso(difficile sbagliare in modo dannoso) rispetto ad alternative come tee </dev/sr0 >image.iso(se si invertono i reindirizzamenti o si dimentica quello di input, teesi scriverà /dev/sr0).
  • cat: è possibile concatenare accidentalmente due file. Ciò lascia i dati facilmente recuperabili.
  • dd: ie osono vicini sulla tastiera e in qualche modo insoliti. Non c'è equivalente di noclobber, of=sovrascriverà felicemente qualsiasi cosa. La sintassi di reindirizzamento è meno soggetta a errori.
  • cp: se si scambiano accidentalmente l'origine e la destinazione, il dispositivo verrà sovrascritto (di nuovo, assumendo un dispositivo non di sola lettura). Se cpviene invocato con alcune opzioni come -Ro -ache alcune persone aggiungono tramite un alias, copierà il nodo del dispositivo anziché il contenuto del dispositivo.

• Funzionalità aggiuntiva L'unico strumento che ha utili funzionalità aggiuntive è pv, con le sue potenti opzioni di reportistica.
  Ma qui puoi controllare quanto è stato copiato guardando comunque la dimensione del file di output.

• Prestazione. Questo è un processo associato a I / O; l'influenza principale sulle prestazioni è la dimensione del buffer: lo strumento legge un blocco dalla sorgente, scrive il blocco sulla destinazione, si ripete. Se il blocco è troppo piccolo, il computer passa il tempo a passare da un'attività all'altra. Se il blocco è troppo grande, le operazioni di lettura e scrittura non possono essere parallelizzate. La dimensione ottimale del blocco su un PC è in genere di alcuni megabyte, ma ciò dipende ovviamente dal sistema operativo, dall'hardware e da ciò che il computer sta facendo. Qualche tempo fa ho fatto benchmark per le copie da disco rigido a disco rigido, su Linux, che ha dimostrato che per le copie all'interno dello stesso disco, dd con una dimensione del buffer di grandi dimensioni ha il vantaggio, ma per le copie su più dischi, ha catvinto su qualsiasi dddimensione del buffer.

Ci sono alcuni motivi per cui trovi ddmenzionato così spesso. A parte le prestazioni, non sono motivi particolarmente validi.

• In sistemi Unix molto vecchi, alcuni strumenti di elaborazione del testo non erano in grado di far fronte ai dati binari (utilizzavano stringhe con terminazione null internamente, quindi tendevano ad avere problemi con byte null; alcuni strumenti presumevano anche che i caratteri usassero solo 7 bit e non lo facevano elaborare correttamente i set di caratteri a 8 bit). Non sono sicuro se questo sia mai stato un problema con cat(è stato con più strumenti line-oriented come head, sede così via), ma la gente tendeva a evitarlo sui dati binari a causa della sua associazione con l'elaborazione del testo. Questo non è un problema su sistemi moderni come Linux, OSX, * BSD o qualsiasi cosa sia conforme a POSIX.
• C'è una sorta di mito che ddè in qualche modo "di livello inferiore" rispetto ad altri strumenti come cate accede direttamente ai dispositivi. Questo è completamente falso: dde cate teetutti gli altri leggono i byte dal loro input e scrivono i byte nel loro output. La vera magia è dentro /dev/sr0.
• ddha un'insolita sintassi della riga di comando, quindi spiegare come funziona dà più di un'opportunità di brillare spiegando qualcosa che semplicemente scrivendo cat /dev/sr0.
• L'uso dd con un buffer di grandi dimensioni può avere prestazioni migliori, ma non è sempre così (vedi alcuni benchmark su Linux ).

Un grave rischio ddè che può saltare silenziosamente alcuni dati . Penso che ddè sicuro fintanto che skipo countnon sono passati, ma io non sono sicuro se questo è il caso su tutte le piattaforme. Ma non ha alcun vantaggio se non per le prestazioni.

Quindi usa solo pvse vuoi il suo rapporto sui progressi, o catse non lo fai.

Ci sono fatti interessanti in questo caso, specialmente questi:

• Ho appena verificato l'output ottenuto e fornito (questa volta ho usato un altro disco, esattamente, il disco di installazione di Xubuntu 15.04 x64) e con entrambe le procedure ( dde pv) i checksum sono identici .
• Ho avuto l'idea di, dopo aver eseguito la ddprocedura, aprire l'unità e chiuderla con lo stesso disco, quindi terminare il test con la pvprocedura. Facendo proprio questo, ho ottenuto copie identiche con entrambe le procedure.
• Io penso che ho avuto diversi checksum la prima volta, perché per qualche motivo, i dati raccolti dall'unità CD / DVD sembra essere "registrato" per altri scopi per un certo tempo (come una cache) - in tal modo, le altre operazioni come checksum erano reso molto più veloce del trasferimento. Si prega di commentare se si conosce la causa esatta per questo.
• Un altro fatto è che ddsenza il count=Xparametro si arresta correttamente alla fine del disco e dà la stessa immagine del disco con pv(i checksum sono identici), quindi è meglio per me usare ddsenza parametri o solo pv.

Quindi, per ora, sembra pve ddpuò realizzare una copia di CD / DVD con gli stessi risultati.