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

22

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!

linux dd cat disk-image pv
la source
les tailles de fichier sont-elles identiques? résultat de cmp file1 file2? avez-vous utilisé ddavec le mauvais count=(ou vraiment n'importe quel nombre qui n'est pas nécessaire si vous voulez le tout?). Lire les erreurs dans dmesg?
frostschutz
2
Il va sans dire que les fichiers de tailles différentes (avec 99,9999999999 + probabilité%) vont avoir des sommes de contrôle différentes. Tant que vous avez fait les tests, il serait bien que vous publiez tous les résultats, pour inclure (1) la ddcommande exacte que vous avez utilisée (quelle taille de bloc? Quel compte?), (2) les tailles et les sommes de contrôle de toutes les sorties et (3) toute information indépendante dont vous disposez concernant la quantité de données sur le disque optique source. ……………… PS Pourquoi utilisez-vous count=sur dd? Vous voulez copier l'intégralité de l'image disque, n'est-ce pas?  count=dit "copiez ce nombre puis arrêtez".
Scott
@Scott Dans cette page linuxjournal.com/content/archiving-cds-iso-commandline, l'auteur dit que l'on devrait utiliser isoinfo -d -i /dev/cdrompour connaître le nombre de comptages et l'utiliser - en fait, il dit qu'on ne devrait pas utiliser uniquement dd. "Dans tous les cas, si vous voulez une image ISO correcte de ce CD, vous devez obtenir la taille et le nombre de blocs corrects avant de créer votre image."
@frostschutz Dans le premier cas, les tailles n'étaient pas identiques, mais étonnamment, j'ai réessayé et obtenu des résultats différents. Voir la réponse que j'ai fournie pour plus de détails.

Réponses:

27

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.

Gilles 'SO- arrête d'être méchant'
la source
Merci beaucoup d'avoir consacré du temps à rédiger cette réponse! =) Maintenant, je comprends les différences entre eux. Juste une question: est pv < /dev/sr0 > image.isole même que pv /dev/sr0 > image.iso(ce dernier se trouve dans les pages de manuel de pv)?
1
@ JBFWP286 Ils copient la même chose, mais pv /dev/sr0 …peuvent inclure le nom de fichier dans les rapports de progression alors qu'ils pv </dev/sr0ne le peuvent pas.
Gilles 'SO- arrête d'être méchant'
Une autre note: cppeut être aliasée cp -R, ce qui (au moins sur GNU cp, en tant que root) entraîne la cpcopie du nœud de périphérique plutôt que son contenu.
marcelm
2
@ JBFWP286 Un nœud de périphérique est un fichier par lequel vous accédez au matériel ou à d'autres fonctionnalités spéciales fournies par les pilotes du noyau. Presque tous les fichiers /devsont des nœuds de périphérique. Par exemple cp -R /dev/sr0 image.iso, créer image.isoun fichier par lequel le lecteur de CD-ROM est accessible, tout comme /dev/sr0, au lieu d'un fichier ordinaire contenant une copie du contenu du CD-ROM que vous obtenez cp /dev/sr0 image.iso.
Gilles 'SO- arrête d'être méchant'
1
@Hashim Je ne conclus pas qu'il a de meilleures performances. Je mentionne qu'il a parfois de meilleures performances . Je suis lié à une référence que j'ai fait - dans le meilleur des cas , ddbattement , catmais seulement par une faible marge.
Gilles 'SO- arrête d'être méchant'
4

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.

Rui F Ribeiro
la source