Pourquoi «dd» produit-il des fichiers différents pour la même clé USB?

Je viens de sauvegarder la restauration pour Windows 8.1 sur une clé USB; maintenant, j'ai créé le niveau faible copie de celui-ci sur mon disque dur, en exécutant la commande suivante:

sudo dd if=/dev/sdf of=/disk2/Archive/windows8.1-restore.img bs=4M oflag=direct

Je voulais vérifier que ma commande 'dd' était ok, donc je l'ai réexécutée deux fois, en spécifiant les deux bs=8M et bs=16M; J'ai vérifié la taille et c'est exactement la même chose, mais md5sum donne une sortie différente pour les trois fichiers:

c38a2b07b3d473d3f1876331edc2647b  windows8.1-restore.img.4M
568e382844431eef63d4ba6dc4c2c5ac  windows8.1-restore.img.8M
568e382844431eef63d4ba6dc4c2c5ac  windows8.1-restore.img.16M

Je crois avoir non monté la clé USB la deuxième et troisième fois.

Devrais-je m'inquiéter de quoi que ce soit?

modifier

La taille totale du fichier est 31024349184 octets dans tous les cas, ma compréhension de bs=xxx est juste de contrôler la vitesse dans le cas où on veut déverser la clé USB / lecteur entier.

— Emanuele
source

Le bâton était-il démonté quand vous avez couru dd avec bs=4M?

— gronostaj

Nan. Je suppose que j'aurais dû, non?

— Emanuele

D'accord, vous devriez l'avoir démonté. (Ou peut-être monté en lecture seule.) Je ne sais pas non plus d'où proviennent vos tailles de blocs. Je voudrais utiliser bs = 512. J'utilise presque toujours bs = 512 sauf lorsque vous utilisez un lecteur de CD car ils peuvent vouloir une taille de bloc différente (comme bs = 2048, ou peut-être bs = 2352 ou quelle que soit la taille de bloc utilisée, comme indiqué par & A; HREF = " osta.org/technology/cdqa7.htm">CD tailles de bloc & lt; / A & gt;).

— TOOGAM

@TOOGAM Voici comment créer des liens .

— gronostaj

@ Emmanuel Je ne pense pas que vous avez tort. Petits blocs avec dd sont connus pour tuer les performances car il oblige beaucoup plus d’appels en lecture et en écriture qu’il ne serait autrement nécessaire. Je pense que gronostaj est correct, votre problème est que vous avez dd'd le disque avec le système de fichiers monté. En supposant que vous n’ayez pas remonté le système de fichiers depuis, vous devriez pouvoir le vérifier en réexécutant votre commande initiale dd; vous devriez également voir une somme MD5 identique à partir de cette invocation.

— a CVn

L'écriture de petites quantités de données sur un lecteur est lente, aussi les tampons système écrivent-ils pour les valider tous en même temps. Lorsque la mémoire tampon contient suffisamment de données pour une opération d'écriture efficace ou lorsque certains processus utilisent sync appel système , le tampon est vidé sur le périphérique.

dd effectue une copie de bas niveau, c.-à-d. il lit les données physiquement présentes sur un périphérique. Il ne prend pas en compte les tampons.

Si le lecteur a été monté lors de l'exécution dd bs=4M, alors il est possible que certaines écritures aient déjà été mises en mémoire tampon, mais non validées. Vous avez vidé le lecteur sans les modifications mises en mémoire tampon.

umount appels sync en interne pour assurer l’intégrité des données. Les périphériques non montés ne sont généralement pas utilisés, à moins que vous ne demandiez explicitement à un processus de le faire. Il était donc peu probable que le lecteur change après le démontage.

Puis tu as couru dd deux fois sur le lecteur sans le monter entre les deux. C'est pourquoi bs=8M et bs=16M les appels ont produit les mêmes résultats.

Drive a été modifié entre bs=4M et bs=8M appelle, cependant, donc le premier vidage est différent. bs= n'a pas d'importance, appeler umount fait.

Vous devez toujours démonter le périphérique avant d'utiliser dd dessus, sinon un autre processus peut modifier son contenu tout en dd fait son travail et brise l'intégrité des fichiers.

— gronostaj
source

Je pensais avoir été un peu idiot de l'avoir monté la première fois quand j'ai exécuté dd. Je suppose que je garderai le fichier pris avec l'appareil non monté . Effrayant!

— Emanuele