Alors, quel est le cas lorsque l’ajout conv=sync,noerrorfait une différence lors de la sauvegarde d’un disque dur entier sur un fichier image? Existe conv=sync,noerror- t-il une exigence lors de la réalisation de travaux de police scientifique? Si tel est le cas, pourquoi s’agit-il de linux fedora?
Modifier:
OK, donc si je ne Dd sans conv=sync,noerror, et des ddrencontres erreur de lecture lors de la lecture du bloc (taille LET 100M), ne dd juste sauter 100M bloc et lit le bloc suivant sans écrire quelque chose ( dd conv=sync,noerrorécrit des zéros à 100M de la production - de sorte que sur cette affaire ?)?
Et si le hachage du disque dur d'origine et du fichier de sortie est-il différent si on le fait sans conv=sync,noerror? Ou est-ce seulement quand une erreur de lecture s'est produite?
Réponses:
conv=syncindiqueddde cadrer chaque bloc à gauche avec des valeurs NULL, de sorte que si, en raison d'une erreur, le bloc complet ne puisse pas être lu, la longueur complète des données d'origine est conservée, même si toutes les données ne peuvent pas être incluses dans l'image. . De cette façon, vous savez au moins à quel point les données sont endommagées, ce qui peut vous fournir des indices, et si vous ne pouvez pas prendre une image du tout à cause de blocs défectueux, vous ne pouvez pas analyser les données. certains sont meilleurs que rien.conv=sync,noerrorest nécessaire pour éviterddde s'arrêter en cas d'erreur et d'effectuer un cliché.conv=syncest en grande partie sans signification sans noerror.http://linuxcommand.org/man_pages/dd1.html
http://vlinux-freak.blogspot.com/2011/01/how-to-use-dd-command.html
la source
dd conv=sync,noerror(ouconv=noerror,sync) corrompt vos données.En fonction de l'erreur d'E / S rencontrée et de la taille de bloc utilisée (supérieure à la taille du secteur physique?), Les adresses d'entrée et de sortie ne restent pas synchronisées, mais aboutissent à des décalages incorrects, ce qui rend la copie inutile pour les images du système de fichiers et autres. les choses où les compensations comptent.
De nombreux endroits recommandent d’utiliser le
conv=noerror,synctraitement des disques défectueux. J'avais l'habitude de faire la même recommandation, moi-même. Cela a fonctionné pour moi, alors que je devais récupérer un mauvais disque il y a quelque temps.Cependant, les tests suggèrent qu'il ne s'agit en réalité d'aucune fiabilité.
Utilisez
losetupetdmsetuppour créer unA error Bappareil:Les dispositifs de boucle A, B ressemblent à ceci:
C'est donc A, B avec des nombres incrémentiels qui nous aideront à vérifier les décalages plus tard.
Maintenant, pour mettre une erreur de lecture entre les deux, gracieuseté du mappeur de périphériques Linux:
Cet exemple crée
AerrorBcomme dans les2000secteurs deA, suivis des2*48secteurs d'erreur, suivis des2000secteurs deB.Juste pour vérifier:
Donc, il lit jusqu'à
A127999\n, puisque chaque ligne a 8 octets qui totalisent 1024000 octets, ce qui correspond à nos 2000 secteurs de 512 octets. Tout semble être en ordre...Est-ce que ça va se mélanger?
Résultats:
Rien que pour la taille des fichiers, vous pouvez savoir que les choses ne vont pas pour certaines tailles de blocs.
Checksums:
ddaccepteddrescueuniquement pour les tailles de bloc qui se trouvent alignées sur notre zone d’erreur (512,4K).Vérifions les données brutes.
Bien que les données elles-mêmes semblent être présentes, elles ne sont évidemment pas synchronisées. les décalages sont complètement décalés pour bs = 16K, 1M, 42,64K ... seules celles avec décalage
2088576sont correctes, comme le prouve le périphérique d'origine.Ce comportement attendu de
dd conv=noerror,sync? Je ne sais pas et les deux implémentationsddque j'avais disponibles ne sont même pas d'accord. Le résultat est très inutile si vous utilisezddun choix de taille de bloc performant.Ce qui précède a été produit en utilisant
dd (coreutils) 8.25,BusyBox v1.24.2,GNU ddrescue 1.21.la source
ddrescueplutôt que deddtravailler avec des disques avec des secteurs défectueux?syncargument lui dit de conserver la longueur correcte de la sortie. Cela ne fonctionne pas si vous utilisez une mauvaise taille de bloc, alors ne le faites pas.iflag=fullblocksemble le sauver. Bien quemd5sumles images créées aveciflag=fullblockencore diffèrent (bien sûr! Étant donné que le nombre d'octets ignorés en raison de l'erreur de lecture diffère - c'est-à-dire que la quantité de\0s dans les images diffère), l'alignement est enregistré aveciflag=fullblock:grep -a -b --only-matching B130000retourne2088576pour toutes les images.