dd
ou toute autre application n'a pas "une sorte de vérification intégrée" dans le sens auquel vous pensez probablement: elle ne lit pas les données du support de stockage pour les comparer avec ce qui a été écrit. C'est le travail du système d'exploitation.
Il n'est pas vraiment possible d'effectuer une lecture-vérification du matériel à partir d'une application. Cela fonctionnerait dans certains scénarios, mais dans la plupart des cas, cela n'aboutirait à rien. L'application pourrait relire ce qu'elle vient d'écrire si elle écrit directement sur un support de stockage , mais cela relira généralement à partir d'un cache en mémoire, ce qui ne donnerait aucune assurance utile. Dans l'exemple que vous citez , dd
écrit sur un tube, et dans ce cas, il n'a aucun contrôle sur ce qui arrive aux données plus loin sur la ligne. Dans votre exemple rsync, une deuxième passe dersync --checksum
est inutile: en théorie, il pourrait attraper une erreur, mais en pratique, si une erreur se produit, alors la deuxième passe ne rapporterait probablement rien de mal, donc vous gaspillez des efforts sur quelque chose qui ne donne pas réellement une assurance utile.
Cependant, les applications ne vérifient ce qui se passe aux données, au sens où ils vérifient que le système d'exploitation a accepté la responsabilité pour les données. Tous les appels système renvoient un état d'erreur. Si un appel système renvoie un état d'erreur, l'application doit propager cette erreur à l'utilisateur, généralement en affichant un message d'erreur et en renvoyant un état de sortie différent de zéro.
Attention, c'est dd
une exception: selon les paramètres de la ligne de commande, dd
peut ignorer certaines erreurs . C'est extrêmement inhabituel: dd
c'est la seule commande courante avec cette propriété. Utilisez à la cat
place de dd
cette façon, vous ne risquez pas la corruption et cela pourrait être plus rapide .
Dans une chaîne de copie de données, deux types d'erreurs peuvent survenir.
- Corruption: un peu est retourné lors du transfert. Il n'y a aucun moyen de vérifier cela au niveau de l'application, car si cela se produit, c'est en raison d'un bug de programmation ou d'une erreur matérielle qui est très susceptible de provoquer la même corruption lors de la lecture. Le seul moyen utile de vérifier qu'aucune telle corruption ne s'est produite est de déconnecter physiquement le support et de réessayer, de préférence sur un autre ordinateur au cas où le problème proviendrait de la RAM.
- Troncature: toutes les données qui ont été copiées ont été copiées correctement, mais certaines des données n'ont pas été copiées du tout. Celui - ci est la peine de vérifier parfois, en fonction de la complexité de la commande. Vous n'avez pas besoin de lire les données pour cela: vérifiez simplement la taille.