Reprise d'un DD d'un disque entier

10

J'écrase mon disque dur avec des données aléatoires en utilisant le bon vieux dd:

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=512

C'est un tableau de 2 To et mon MacBook (fonctionnant sous Linux, ok?) Ne peut écrire que des données à environ 3,7 Mo / s, ce qui est assez pathétique car j'ai vu mon bureau à la maison faire 20 Mo / s. Quand je rentre chez moi ce soir, j'aimerais arrêter la ddcourse ici, le ramener à la maison et voir quel genre de progrès peut être fait du jour au lendemain avec une machine plus puissante.

J'ai suivi les progrès à l'aide d'une simple boucle:

while true; do kill -USR1 $PID ; sleep 10 ; done

La sortie ressemble à ceci:

464938971+7 records in
464938971+7 records out
238048755782 bytes (238 GB) copied, 64559.6 s, 3.7 MB/s

Si je devais reprendre le ddpass à la maison, comment le redémarrer? Je connais le seekparamètre, mais à quoi dois-je faire référence, le numéro d'enregistrement ou le nombre d'octets?

dd Naftuli Kay
la source
1
Dois-je utiliser le numéro d'enregistrement? Est-ce que cela équivaut au nombre de blocs écrits?
Naftuli Kay
2
Le nombre de blocs = total octets / taille de bloc, en théorie, il devrait être 238048755782/512 = 464938976 mais vous avez des enregistrements partiels là-bas, donc je soustrais quelques blocs du nombre juste pour être sûr, par exempleseek=464938960
don_crissti

Réponses:

8

Comme l'a déjà commenté @don_crissti, utilisez simplement seek=pour reprendre.

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=512 seek=464938971

GNU dd prend également en charge la recherche en octets, afin que vous puissiez reprendre exactement, quelle que soit la taille du bloc:

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=1M \
   seek=238048755782 oflag=seek_bytes

Une taille de bloc plus grande devrait aider avec des vitesses même pour un appareil lent comme /dev/urandom.

Si vous cherchez des alternatives plus rapides, vous pourriez cryptsetup plainOpenavec une clé aléatoire et zéro, elle devrait battre /dev/urandompar un ordre de grandeur (sans AES-NI) ou même fonctionner à pleine vitesse (avec AES-NI).

Vous pouvez également utiliser shred -n 1si les données pseudo-aléatoires sont suffisantes pour votre cas d'utilisation. shreddevrait pouvoir utiliser la vitesse totale du disque, même sur une machine très lente.

frostschutz
la source
Je n'en savais rien plainOpenjusqu'à maintenant. Génial! Fini mon brouillage d'un disque de 2 To en environ 4 heures, contre 256 Go en plus de 12 /dev/urandom.
Naftuli Kay du
3

Juste un rappel pour les personnes qui souhaitent copier plutôt que de simplement randomiser des disques (ce qui n'est pas si courant): vous pouvez utiliser skip=BLOCKSpour commencer à lire à la bonne position et seek=BLOCKScommencer à écrire à la bonne position. Les deux options utilisent des blocs, pas des octets. Lors de l'arrêt / redémarrage, il est conseillé de supprimer un tas de blocs au cas où. Il vaut généralement la peine d'augmenter la bsvaleur au-dessus de 512, car vous pouvez obtenir de meilleures performances si vous lisez beaucoup de données d'affilée.

Dans votre cas, c'est en effet une valeur de bloc à laquelle vous devez passer seek. Vous devriez peut-être essayer de vous ajuster bspour voir si vous pouvez améliorer la vitesse, comme cela /dev/randomdevrait aller vite (pseudo-aléatoire et non bloquant quand il n'y a pas d'entropie disponible)

Uriel
la source
0

ddavec une taille de bloc minuscule comme 512 octets est susceptible d'être beaucoup plus lent que le débit maximal de votre disque. Utilisez une taille de bloc plus élevée (sur une intuition, je dirais quelques Mo) pour de bonnes performances. Ou utilisez cat- sur Linux, j'ai trouvé catque c'était aussi rapide ddqu'avec la taille de bloc optimale quand un seul disque était impliqué (je ne sais pas si cela vaut aussi pour OSX).

Pour savoir jusqu'où cata été atteint, exécutez lsof -p1234où 1234 est l'ID de catprocessus du processus.

Pour reprendre à partir d'une position, utilisez

{ dd bs=1 seek=123456; cat /dev/urandom; } >/dev/disk/…

où 123456 est le décalage en octets.

Gilles 'SO- arrête d'être méchant'
la source
0

Clonage d'un disque:

En développant cette réponse à partir de ce fil, voici comment on pourrait procéder pour cloner un disque entier et reprendre:

Cet exemple est optimisé pour la copie d'un lecteur rotatif à 5400 tr / min vers un SSD sur un système spécifique. gddreprésente GNU dd:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' bs=4M status=progress
247426187264 bytes (247 GB, 230 GiB) copied, 2082 s, 119 MB/s
59012+0 records in
59011+0 records out
247510073344 bytes (248 GB, 231 GiB) copied, 2082.92 s, 119 MB/s

Je peux reprendre cela de deux manières:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' \
bs=4M \
seek=59011 skip=59011 \
status=progress

Ou:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' \
bs=4M \
seek=247510073344 skip=247510073344 \
oflag=seek_bytes iflag=skip_bytes \
status=progress

Dans le premier exemple, la raison pour laquelle nous utilisons 59011et non 59012, c'est parce 59011que le nombre d'enregistrements de taille de bloc a été entièrement copié avant d'être interrompu. (enregistre).

hmedia1
la source