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

Toutes les commands suivantes sont équivalentes. Ils lisent les octets du CD /dev/sr0 et les écrivent dans un file 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 utiliseriez-vous l'un sur l'autre?

• Simplicité. Par exemple, si vous connaissez déjà cat ou cp , vous n'avez pas besoin d'apprendre encore une autre command.

• Robustesse. Celui-ci est un peu une variante de la simplicité. Quel risque y a-t-il que le changement de la command va changer ce qu'elle fait? Voyons quelques exemples:

  • Tout ce qui a une redirection: vous pourriez accidentellement mettre une redirection dans le mauvais sens, ou l'oublier. Puisque la destination est censée être un file set -o noclobber , set -o noclobber devrait s'assurer que vous set -o noclobber rien; mais vous risquez d'écraser un périphérique si vous écrivez accidentellement >/dev/sda (pour un CD qui est en lecture seule, il n'y a pas de risque, bien sûr). Ceci est en faveur de cat /dev/sr0 >image.iso (difficile de se tromper de façon dommageable) par rapport à des alternatives telles que tee </dev/sr0 >image.iso (si vous inversez les redirections ou oubliez l'input un, tee écrira à /dev/sr0 ).
  • cat : vous pourriez accidentellement concaténer deux files. Cela laisse datatables facilement récupérables.
  • dd : i et o sont proches sur le keyboard, et quelque peu inhabituel. Il n'y a pas d'équivalent de noclobber , of= écrasera heureusement n'importe quoi. La syntaxe de redirection est less sujette aux erreurs.
  • cp : si vous échangez accidentellement la source et la cible, l'appareil sera écrasé (encore une fois, en supposant un périphérique non-lecture seule). Si cp est invoqué avec certaines options telles que -R ou -a que certaines personnes ajoutent via un alias, il copyra le noeud du périphérique plutôt que le contenu du périphérique.

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

• Performance. C'est un process lié aux E / S; l'influence principale dans la performance est la taille de la memory tampon: l'outil lit un morceau de la source, écrit le morceau à la destination, répète. Si le bloc est trop petit, l'ordinateur passe son time à basculer entre les tâches. Si le bloc est trop volumineux, les opérations de lecture et d'écriture ne peuvent pas être parallélisées. La taille de morceau optimale sur un PC est généralement de l'ordre de quelques mégaoctets, mais cela dépend évidemment du operating system, du matériel et de tout ce que fait l'ordinateur. J'ai fait des benchmarks pour le disque dur sur les copys du disque dur il y a un certain time, sur Linux, qui montrait que pour les copys sur le même disque, dd avec une grande taille de tampon a l'avantage, mais pour les copys cross-disk, Taille.

Il y a quelques raisons pour lesquelles vous trouvez dd mentionné si souvent. En dehors de la performance, ils ne sont pas particulièrement bonnes raisons.

• Dans les très vieux systèmes Unix, les outils de traitement de text tels que cat ne pouvaient pas gérer datatables binarys. 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 y a une sorte de mythe selon lequel dd est un peu plus bas que d'autres outils tels que cat et accède directement aux périphériques. Ceci est complètement faux: dd et cat et tee et les autres lisent tous les octets de leur input et écrivent les octets à leur sortie. La vraie magie est dans /dev/sr0 .
• dd a une syntaxe de command line inhabituelle, donc expliquer comment cela fonctionne donne plus une opportunité de briller en expliquant quelque chose qui vient d'écrire cat /dev/sr0 .
• L'utilisation de dd avec une grande taille de memory tampon peut avoir de meilleures performances.

Un risque majeur avec dd est qu'il peut ignorer silencieusement certaines données . Je pense que dd est sûr aussi longtime que skip ou count ne sont pas passés mais je ne suis pas sûr que ce soit le cas sur toutes les plateforms. Mais il n'a aucun avantage sauf pour la performance.

Donc, utilisez simplement pv si vous voulez son rapport d'avancement de fantaisie, ou cat si 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 et fournie (j'ai utilisé un autre disque cette fois-ci, exactement, le disque d'installation Xubuntu 15.04 x64) et avec les deux procédures ( dd et pv ) les sums de contrôle sont identiques .
• J'ai eu l'idée, après avoir fait la procédure dd , d'ouvrir le lecteur et de le fermer avec le même disque, puis de terminer le test avec la procédure pv . En faisant cela, j'ai obtenu des copys identiques avec les deux procédures.
• Je pense que j'ai des checksums différents la première fois, parce que pour une raison quelconque, datatables collectées depuis le lecteur de CD / DVD semblent être "enregistrées" à d'autres fins pendant un certain time (comme un cache) fait beaucoup plus vite que le transfert. S'il vous plaît commenter si vous connaissez la cause exacte de cela.
• Un autre fait est que dd avec le paramètre count=X s'arrête correctement à la fin du disque et donne la même image disque qu'avec pv (les checksums sont identiques), donc il vaut mieux que j'utilise dd w / o parameters ou juste pv .

Donc, pour l'instant, il semble que pv et dd puissent réaliser une copy de CD / DVD avec les mêmes résultats.

J'espère que cela aide à tout le monde! Sentez-vous libre et commentez les autres détails que vous connaissez à ce sujet.