Formater usb et confirmer tous les zéros
Je veux formater mon lecteur USB et confirmer qu'il a été rempli avec des zéros. Pour formater c'est la commande que j'utilise: Sudo mkfs.vfat -I /dev/sdb
Comment puis-je confirmer que le périphérique est rempli de tous les zéros via la ligne de commande?
Appliquez dd et tr pour l'inspection virtuelle:
dd if=/dev/sdb | tr '\0' 0
Appliquez dd et grep pour la vérification automatique:
dd if=/dev/sdb | grep -zq . && echo non zero
Ce qui précède est nettement plus lent que la commande optimisée ci-dessous:
grep -zq . /dev/sdb && echo non zero
grep -z lit les lignes délimitées par des caractères nuls. Si tous les octets sont nuls, chaque ligne est vide. . ne doit donc jamais correspondre.
Bien sûr, cela ne sera pas vrai pour une partition formatée - le système de format utilisera des octets et ceux-ci seront non nuls.
Je vais aussi lancer mon chapeau sur le ring. Une alternative que j'aime utiliser est scrub. C'est dans les dépôts, donc pour l'installer à partir d'une fenêtre de terminal, tapez:
Sudo apt-get install scrub
scrub prend en charge de nombreux types de motifs de nettoyage
Available patterns are:
nnsa 3-pass NNSA NAP-14.1-C
dod 3-pass DoD 5220.22-M
bsi 9-pass BSI
usarmy 3-pass US Army AR380-19
random 1-pass One Random Pass
random2 2-pass Two Random Passes
schneier 7-pass Bruce Schneier Algorithm
pfitzner7 7-pass Roy Pfitzner 7-random-pass method
pfitzner33 33-pass Roy Pfitzner 33-random-pass method
gutmann 35-pass Gutmann
fastold 4-pass pre v1.7 scrub (skip random)
old 5-pass pre v1.7 scrub
dirent 6-pass dirent
fillzero 1-pass Quick Fill with 0x00
fillff 1-pass Quick Fill with 0xff
custom 1-pass custom="string" 16b max, use escapes \xnn, \nnn, \\
Pour utiliser scrub afin de remplir le lecteur de tous les zeros, vérifiez d’abord que le lecteur n’est pas monté. Ensuite, lancez la ligne suivante (-p signifie le motif à utiliser):
Sudo scrub -p fillzero /dev/sdX
alors vous devriez voir quelque chose comme ça:
scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00 |..... |
Certains des modèles utilisés pour le récurage doivent avoir un verify passe pour s'assurer que le récurage est réussi.
Si vous le souhaitez, vous pouvez ajouter la hexdump (comme dans la réponse de Byte Commander) ou l'une des autres réponses à la fin de la vérification.
J'espère que cela t'aides!
Utilisation de cmp (merci à muru d’avoir souligné la stupidité de l’utilisation d’un tuyau):
Sudo cmp /dev/zero /dev/sdX
Si vous obtenez une sortie telle que celle-ci:
cmp: EOF on /dev/sdX
Le lecteur est rempli de zéro.
% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo
Ma suggestion serait hexdump. Il affiche le contenu de tout fichier ou périphérique au format hexadécimal sous forme de lignes de 16 octets. Toutefois, si deux lignes sous-séquentielles sont égales, il les omet.
Voici un exemple de sortie du fichier 512 Mo virtualdevice qui est rempli de zéros uniquement sur le répertoire actuel de mon disque dur. La colonne la plus à gauche est le décalage de la ligne en notation hexadécimale, les 8 colonnes suivantes représentent les données réelles, regroupées sur deux octets (4 caractères hexadécimaux):
$ hexdump ./virtualdevice
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000
Performance:
J'ai fait l'effort et comparé ma solution aux autres solutions en termes de temps d'exécution réel et de temps CPU pour le fichier d'exemple décrit (512 Mo, ne contenant que des zéros binaires, situés sur le disque dur).
J'ai mesuré chaque solution avec la commande time deux fois avec un cache de disque récemment effacé et deux fois avec le fichier en cours de mise en cache. Les noms d'heure sont égaux à ceux de la commande time et la ligne supplémentaire CPU correspond simplement à la somme de USER + SYS fois. Il peut dépasser le temps REAL car j'utilise une machine bicœur.
Pour la plupart des gens, les chiffres intéressants sont REAL (heure du début à la fin, comme si elle était mesurée avec un chronomètre. Cela contient également IO wait et le temps processeur d'autres processus) et CPU (temps CPU réellement occupé par la commande).
Résumé:
La meilleure performance a la deuxième version optimisée de mur (grep -zq . DEVICE) qui utilise incroyablement peu de temps de traitement du processeur.
Rang 2 partage cmp /dev/zero DEVICE (kos 'solution optimisée) et ma propre solution hexdump DEVICE. Il n'y a presque pas de différence entre eux.
Pour diriger les données de dd à cmp (dd if=/dev/zero | cmp - DEVICE - kos 'solution non optimisée) est très inefficace, la tuyauterie semble prendre beaucoup de temps de traitement.
L’utilisation de dd et de grep montre les performances de loin les plus mauvaises des commandes testées.
Conclusion:
Bien que la partie la plus critique des opérations de ce type soit le IO _ temps d'accès, il existe des différences significatives dans la vitesse de traitement et l'efficacité des approches testées.
Si vous êtes très impatient, utilisez la deuxième version de la réponse de mur (grep -zq . DEVICE)!
Mais vous pouvez aussi bien utiliser la seconde version de kos 'answer (cmp /dev/zero DEVICE) ou la mienne (hexdump device), car ils ont presque aussi bon performance.
Toutefois, mon approche présente l’avantage de voir immédiatement le contenu du fichier et de savoir approximativement le nombre d’octets différents de zéro et leur emplacement. Si vous avez beaucoup de données en alternance, la sortie grandira et ralentira probablement.
Dans tous les cas, vous devez éviter d'utiliser dd et des tubes. Les performances de dd pourraient probablement être améliorées en définissant une taille de mémoire tampon appropriée, mais pourquoi le faire de manière aussi compliquée?
Veuillez également noter à nouveau que le test a été effectué sur un fichier de mon disque plutôt que sur un périphérique réel. De plus, le fichier ne contenait que des zéros. Les deux affecte les performances.
Voici les résultats détaillés:
hexdump ./virtualdevice(ma propre solution):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.689s 8.668s | 1.868s 1.930s USER | 1.816s 1.720s | 1.572s 1.696s SYS | 0.408s 0.504s | 0.276s 0.220s CPU | 2.224s 2.224s | 1.848s 1.916sdd if=./virtualdevice | grep -zq . && echo non zero(solution non optimisée de mur):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 9.434s 11.004s | 8.802s 9.266s USER | 2.264s 2.364s | 2.480s 2.528s SYS | 12.876s 12.972s | 12.676s 13.300s CPU | 15.140s 15.336s | 15.156s 15.828sgrep -zq . ./virtualdevice && echo non zero(solution optimisée de mur):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 8.763s 6.485s | 0.770s 0.833s USER | 0.644s 0.612s | 0.528s 0.544s SYS | 0.440s 0.476s | 0.236s 0.264s CPU | 1.084s 1.088s | 0.764s 0.808sdd if=/dev/zero | cmp - ./virtualdevice(kos 'solution non optimisée):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.678s 6.539s | 3.151s 3.147s USER | 2.348s 2.228s | 2.164s 2.324s SYS | 3.672s 3.852s | 3.792s 3.516s CPU | 6.020s 6.080s | 5.956s 5.840scmp /dev/zero ./virtualdevice(kos 'solution optimisée):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 6.340s 9.183s | 1.660s 1.660s USER | 1.356s 1.384s | 1.216s 1.288s SYS | 0.640s 0.596s | 0.428s 0.360s CPU | 1.996s 1.980s | 1.644s 1.648s
Commandes utilisées:
Pour les quatre tests, j'ai exécuté la procédure suivante deux fois afin de réduire les imprécisions, en remplaçant <COMMAND> par la commande exacte figurant dans l'en-tête de chaque tableau.
Laissez le noyau supprimer tous les caches de disque:
sync && echo 3 | Sudo tee /proc/sys/vm/drop_cachesPremière exécution chronométrée (non mise en cache), le fichier est chargé dans le cache au cours de cette opération:
time <COMMAND>Deuxième exécution chronométrée (mise en cache). Cette fois, la plupart des données sont extraites de la mémoire cache du disque dans la RAM. C'est donc beaucoup plus rapide que d'accéder directement au disque:
time <COMMAND>