Est-il préférable d'utiliser cat, dd, pv ou une autre procédure pour copier un CD / DVD?

Contexte

Je copie des CD / DVD de données dans des fichiers ISO pour les utiliser plus tard sans en avoir besoin dans le lecteur.

Je cherche sur le net des procédures et j'en ai trouvé beaucoup:

• Utilisation de catpour copier un support: http://www.yolinux.com/TUTORIALS/LinuxTutorialCDBurn.html

  cat /dev/sr0 > image.iso
  

• Utilisation de ddpour le faire (apparemment le plus utilisé): http://www.linuxjournal.com/content/archiving-cds-iso-commandline

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

• Utilisation de juste pvpour accomplir ceci: Voir man pvpour plus d'informations, bien qu'en voici un extrait:

  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
  

Je ne sais pas si tous devraient être équivalents, bien que j'en ai testé certains (en utilisant l' md5sumoutil) et, au moins, ddet nepv soient pas équivalents. Voici à la md5sumfois le lecteur et les fichiers générés à l'aide de chaque procédure:

md5 de la procédure dd: 71b676875b0194495060b38f35237c3c

md5 de la procédure pv: f3524d81fdeeef962b01e1d86e6acc04

EDIT: Cette sortie provenait d'un autre CD que la sortie donnée. En fait, j'ai réalisé qu'il y avait des faits intéressants que je fournissais comme réponse.

En fait, la taille de chaque fichier est différente par rapport à l'autre.

Alors, existe-t-il une meilleure procédure pour copier un CD / DVD ou est-ce que j'utilise les commandes de manière incorrecte?

Plus d'informations sur la situation

Voici plus d'informations sur le scénario de test que j'utilise pour vérifier les procédures que j'ai trouvées jusqu'à présent:

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

ddde copier les médias, avec checksums de sortie et informations sur l' image de sortie: https://gist.github.com/JBFWP286/75decda0a67605590d32#file-dd-output-with-md5-and-sha256-19-aug-2015

pvde copier les médias, avec checksums de sortie et informations sur l' image de sortie: https://gist.github.com/JBFWP286/700a13fe0a2f06ce5e7a#file-pv-output-with-md5-and-sha256-19-aug-2015

Toute aide serait appréciée!

Toutes les commandes suivantes sont équivalentes. Ils lisent les octets du CD /dev/sr0et les écrivent dans un fichier appelé 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

Pourquoi voudriez-vous utiliser l'un sur l'autre?

• Simplicité. Par exemple, si vous connaissez déjà catou cp, vous n'avez pas besoin d'apprendre une autre commande.

• Robustesse. Celui-ci est un peu une variante de simplicité. Quel est le risque que la modification de la commande modifie son action? Voyons quelques exemples:

  • Tout ce qui a une redirection: vous pourriez accidentellement mettre une redirection dans le mauvais sens, ou l'oublier. Étant donné que la destination est censée être un fichier inexistant, set -o noclobbervous devez vous assurer de ne rien écraser; cependant, vous pourriez écraser un périphérique si vous écrivez accidentellement >/dev/sda(pour un CD, qui est en lecture seule, il n'y a aucun risque, bien sûr). Cela parle en faveur de cat /dev/sr0 >image.iso(difficile de se tromper de manière dommageable) par rapport à des alternatives telles que tee </dev/sr0 >image.iso(si vous inversez les redirections ou oubliez l'entrée, vous teeallez écrire /dev/sr0).
  • cat: vous pouvez accidentellement concaténer deux fichiers. Cela laisse les données facilement récupérables.
  • dd: iet osont proches du clavier, et quelque peu inhabituel. Il n'y a pas d'équivalent noclobber, of=écrasera volontiers quoi que ce soit. La syntaxe de redirection est moins sujette aux erreurs.
  • cp: si vous échangez accidentellement la source et la cible, le périphérique sera écrasé (encore une fois, en supposant un périphérique non en lecture seule). Si cpest invoqué avec certaines options telles que -Rou -aque certaines personnes ajoutent via un alias, il copiera le nœud du périphérique plutôt que le contenu du périphérique.

• Fonctionnalité supplémentaire. Le seul outil ici qui possède des fonctionnalités supplémentaires utiles est pv, avec ses puissantes options de génération de rapports.
  Mais ici, vous pouvez vérifier combien a été copié en regardant la taille du fichier de sortie de toute façon.

• Performance. Il s'agit d'un processus lié aux E / S; la principale influence sur les performances est la taille du tampon: l'outil lit un morceau de la source, écrit le morceau dans la destination, répète. Si le bloc est trop petit, l'ordinateur passe son temps à basculer entre les tâches. Si le bloc est trop grand, les opérations de lecture et d'écriture ne peuvent pas être parallélisées. La taille de bloc optimale sur un PC est généralement de l'ordre de quelques mégaoctets, mais cela dépend évidemment beaucoup du système d'exploitation, du matériel et de ce que l'ordinateur fait d'autre. J'ai fait des tests de performances pour les copies de disque dur à disque dur il y a un certain temps, sous Linux, ce qui a montré que pour les copies sur le même disque, dd avec une grande taille de tampon a l'avantage, mais pour les copies inter-disques, a catgagné sur n'importe quelle ddtaille de tampon.

Il y a plusieurs raisons pour lesquelles vous trouvez ddsi souvent mentionné. Mis à part les performances, ce ne sont pas des raisons particulièrement bonnes.

• Dans les très anciens systèmes Unix, certains outils de traitement de texte ne pouvaient pas gérer les données binaires (ils utilisaient des chaînes terminées par null en interne, ils avaient donc tendance à avoir des problèmes avec les octets nuls; certains outils supposaient également que les caractères n'utilisaient que 7 bits et non traiter correctement les jeux de caractères 8 bits). Je ne sais pas si cela a jamais été un problème cat(il était avec plus d' outils orientés ligne tels que head, sed, etc.), mais les gens avaient tendance à éviter sur des données binaires en raison de son association avec le traitement de texte. Ce n'est pas un problème sur les systèmes modernes tels que Linux, OSX, * BSD ou tout ce qui est compatible POSIX.
• Il existe une sorte de mythe qui ddest quelque peu «de niveau inférieur» par rapport à d'autres outils tels que catet accède directement aux appareils. C'est complètement faux: ddet catet teeet les autres lisent tous les octets de leur entrée et écrivent les octets dans leur sortie. La vraie magie est là /dev/sr0.
• dda une syntaxe de ligne de commande inhabituelle, donc expliquer comment cela fonctionne donne plus de chance de briller en expliquant quelque chose qui ne fait qu'écrire cat /dev/sr0.
• L'utilisation dd avec une grande taille de tampon peut avoir de meilleures performances, mais ce n'est pas toujours le cas (voir quelques benchmarks sous Linux ).

Un risque majeur ddest qu'il peut ignorer silencieusement certaines données . Je pense que ddc'est sûr aussi longtemps skipou countnon, mais je ne suis pas sûr que ce soit le cas sur toutes les plateformes. Mais cela n'a aucun avantage sauf pour les performances.

Il suffit donc de l'utiliser pvsi vous voulez son rapport d'avancement de fantaisie, ou catsi vous ne le faites pas.

Il y a des faits intéressants dans ce cas, spécialement ceux-ci:

• Je viens de vérifier la sortie que j'ai obtenue et fournie (j'ai utilisé un autre disque cette fois, exactement, le disque d'installation de Xubuntu 15.04 x64), et avec les deux procédures ( ddet pv) les sommes de contrôle sont identiques .
• J'ai eu l'idée, après avoir fait la ddprocédure, d'ouvrir le lecteur et de le fermer avec le même disque, puis de terminer le test avec la pvprocédure. Ce faisant, j'ai obtenu des copies identiques avec les deux procédures.
• Je pense que j'ai obtenu des sommes de contrôle différentes la première fois, car pour une raison quelconque, les données collectées à partir du lecteur de CD / DVD semblent être "enregistrées" à d'autres fins pendant un certain temps (comme un cache) - ainsi, d'autres opérations comme les sommes de contrôle ont été fait beaucoup plus rapide que le transfert. Veuillez commenter si vous connaissez la cause exacte de cela.
• Un autre fait est que ddsans le count=Xparamètre, il s'arrête correctement à la fin du disque et donne la même image disque qu'avec pv(les sommes de contrôle sont identiques), il est donc préférable pour moi d'utiliser ddsans paramètres ou simplement pv.

Donc, pour l'instant, il semble pvet ddpeut accomplir une copie CD / DVD avec les mêmes résultats.