Pourquoi GNU est-il plus rapide que dd lors du remplissage d'un disque avec des données aléatoires?


8

Tout en effaçant en toute sécurité un disque dur avant la mise hors service, j'ai remarqué que cela dd if=/dev/urandom of=/dev/sdaprend presque une journée entière, alors que cela shred -vf -n 1 /dev/sdane prend que quelques heures avec le même ordinateur et le même lecteur.

Comment est-ce possible? Je suppose que le goulot d'étranglement est la sortie limitée de /dev/urandom. Shred utilise-t-il un générateur de pseudo-aléatoire qui est moins aléatoire et seulement suffisant pour son objectif unique (c'est-à-dire plus efficace) que urandom?


Notez que la meilleure option pour effacer les disques, en particulier les disques SSD, est la commande d'effacement sécurisé SATA. Toute autre option - sauf destruction - échouera. C'est beaucoup plus rapide aussi, et cela peut prendre quelques secondes sur un SSD.
Maarten Bodewes

Réponses:


11

Shred utilise un générateur pseudo-aléatoire interne

Par défaut, ces commandes utilisent un générateur pseudo-aléatoire interne initialisé par une petite quantité d'entropie, mais peuvent être dirigées pour utiliser une source externe avec l'option --random-source = file. Une erreur est signalée si le fichier ne contient pas suffisamment d'octets.

Par exemple, le fichier de périphérique / dev / urandom pourrait être utilisé comme source de données aléatoires. En règle générale, ce périphérique collecte le bruit environnemental des pilotes de périphériques et d'autres sources dans un pool d'entropie et utilise le pool pour générer des bits aléatoires. Si le pool est à court de données, l'appareil réutilise le pool interne pour produire plus de bits, en utilisant un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé. Mais sachez que cet appareil n'est pas conçu pour la génération de données aléatoires en masse et qu'il est relativement lent .

Je ne suis pas convaincu que les données aléatoires soient plus efficaces qu'un seul passage de zéros (ou toute autre valeur d'octet) pour masquer le contenu précédent.

Pour mettre hors service un variateur en toute sécurité, j'utilise un gros aimant et un gros marteau.


2

Je suppose que cela serait plutôt dû à l' ddutilisation de petits morceaux pour écrire les données. Essayez dd if=... of=... bs=(1<<20)de voir s'il fonctionne mieux.


Je vais essayer cela à la prochaine occasion et publier les résultats.

+1 La ddtaille de bloc par défaut est 512. Il s'est déroulé bien en dessous des limites du disque sur mon ordinateur.
Piotr Findeisen

/ dev / urandom est probablement très rapide - la taille du bloc dd est presque certainement le problème.
Dan Pritts

2
Une fois que vous augmentez la taille du bloc, il semble que cela /dev/urandompuisse devenir un goulot d'étranglement - je teste certains lecteurs SSD sur USB 3.0 et avec la même ddcommande, j'obtiens 326 Mo / s pour if=/dev/zeromais seulement 12,8 Mo / s pourif=/dev/urandom
Austinmarton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.