Est-ce que dd est meilleur que cat ?

Question

Supposons que je veuille cloner mon disque dur ( hda ) vers un autre lecteur ( hdb ) dans le même ordinateur. Comme je le vois, il y a deux moyens faciles, approximatifs et à faire soi-même :

cat /dev/hda > /dev/hdb

y

dd if=/dev/hda of=/dev/hdb

Quelles sont les raisons techniques pour lesquelles on dit souvent/toujours que la seconde est meilleure que la première ?

n'essayez en aucun cas ces commandes à la maison, ou votre UNIX est fichu.

Answer 1

La grande différence entre 'cat' et 'dd' est que dd s'assure que toutes les lectures et écritures sont effectuées avec la taille que vous avez spécifiée. Cela peut être important, selon le périphérique (et la version de *nix) que vous utilisez.

Answer 2

Quelques points.

ltrace cat </dev/zero >/dev/null suggère que le chat est plus efficace par défaut car il ne fait pas de memcpy et surtout utilise des tampons de 4KiB par défaut.

ltrace dd if=/dev/zero of=/dev/null montre que dd utilise par défaut 512B, ce qui est très inefficace pour la lecture de disques modernes (bien que le noyau devrait atténuer quelque peu ce problème grâce à diverses programmations de disques). Cependant, dd est beaucoup plus configurable que cat et vous pouvez utiliser quelque chose comme bs=2M pour réduire le nombre de syscalls

dd est problématique en présence d'erreurs de disque, et peut se bloquer ou, plus important, ignorer les données non lisibles, corrompant ainsi le disque de destination. Considérez plutôt dd_rescue ou ddrescue pour cette tâche.

Answer 3

C'est vraiment historique, et pas très important si vous ne faites que cloner un disque sur un autre.

Sur Unix traditionnel, les disques étaient accessibles à la fois par des périphériques de blocs et des périphériques de caractères, et chacun avait des exigences différentes. Le programme " dd " était nécessaire pour interagir avec les périphériques blocs, car " cat " ne connaissait que les E/S de caractères. (Les E/S par bloc étaient particulièrement importantes pour gérer efficacement des choses comme les lecteurs de bandes).

dd peut être pratique si vous devez relancer une copie de longue durée, grâce à ses options de saut et de recherche.

À moins que vous ne soyez sur un système qui utilise encore la distinction bloc/caractère pour l'accès au disque (ce qui n'est pas le cas de Linux), et à moins que vous n'ayez besoin de faire quelque chose comme échanger des octets, 'cat' sera parfait (et probablement plus rapide, car il utilisera par défaut des tailles de blocs plus grandes que dd).

Notez que, à moins que quelqu'un n'ait fait des modifications majeures dans la conception du shell depuis la dernière fois que j'ai regardé, 'cat foo >bar' fait no effectuer l'écriture dans 'bar' via l'interpréteur de commandes ; tout ce que fait l'interpréteur de commandes est d'ouvrir 'bar' pour l'écriture avec troncature, puis de passer le descripteur de fichier ouvert à 'cat' à travers un fork/exec comme descripteur de fichier 1 (stdout). À ce stade, l'interpréteur de commandes est hors de la boucle et n'intervient plus, si ce n'est pour être informé de l'état de sortie de 'cat'.

Answer 4

Je pense qu'il pourrait y avoir une pénalité de performance pour envoyer toutes vos données par le tuyau. dd fait tout dans un programme, et est probablement optimisé pour les lectures et écritures de blocs.

Answer 5

La question devrait probablement être "Est-ce que dd est meilleur que cat ?". La réponse va probablement dépendre de beaucoup d'autres facteurs. Le seul moyen réel de le savoir serait de procéder à des tests réels.