Pourquoi DD prend trop de temps?

17

J'ai besoin de copier un disque sur un autre. J'ai essayé avec la commande ci-dessous et il faut presque un jour pour copier 1 To de disque dans federo.

dd if=/dev/sda of=/dev/sdb 

J'ai essayé la même chose sur un système Unix (HP-UX) avec la commande ci-dessous et elle se termine en quelques heures

dd if=/dev/sda of=/dev/rdsk

Quelle est l'alternative que je pourrais utiliser pour copier d'un disque à un disque plus rapidement?

KKD
la source
2
cp /dev/sda /dev/sdbou ( pv /dev/sda > /dev/sdb pour obtenir une barre de progression) serait beaucoup plus rapide. Pourquoi utiliseriez-vous ddici? ddne serait utile qu'avec des choses comme conv=sync,noerrorgérer des disques avec des erreurs, mais même alors, il serait plus logique d'utiliser des choses comme à la ddrescueplace (voir aussi pvl' -Eoption de).
Stéphane Chazelas
1
@ StéphaneChazelas catpeut être encore plus rapide mais la différence n'est pas si dramatique (peut-être plus grande pour appareil à appareil que fichier à fichier comme dans mon expérience).
Gilles 'SO- arrête d'être méchant'
8
"J'ai essayé la même chose sur un système Unix" - Alors sur quel type de système avez-vous essayé le premier, sinon un Unix? Aussi, quel matériel, etc., yaddayadda.
marcelm
Bienvenue à l' ddécueil # 1
Dmitry Grigoryev
Utilisé le premier dans HP-UX (lame Integrity) et la machine Solaris précédemment utilisée également.
KKD

Réponses:

28

dda de nombreuses options (étranges), voir dd (1) .

Vous devez indiquer explicitement la taille du tampon, alors essayez

dd if=/dev/sda of=/dev/sdb bs=16M

IIRC, la taille de tampon par défaut n'est que de 512 octets. La commande ci-dessus la définit à 16 mégaoctets. Vous pouvez essayer quelque chose de plus petit (par exemple bs=1M), mais vous devez utiliser plus que la valeur par défaut (en particulier sur le matériel de disque récent avec des secteurs de 4 Ko, c'est-à-dire le format avancé ). Je recommande naïvement une puissance de deux qui est au moins un mégaoctet.

Avec la taille de tampon de 512 octets par défaut, je suppose (mais je peux me tromper) que le matériel nécessite que le noyau transfère 4K pour chaque bloc de 512 octets.

Concernant rdsk, les pages de manuel de sd (4) disent:

Pour le moment, seuls les périphériques bloc sont fournis. Les appareils bruts n'ont pas encore été implémentés.

L'augmentation de la taille du tampon de dd vous donnera plus de performances pour les opérations de lecture et d'écriture. Maintenant, tous les disques ont un tampon de lecture / écriture matériel. Mais si vous augmentez la taille du tampon de dd plus que le tampon matériel, ses performances diminueront car dd lira du premier disque au tampon lorsque le second disque aura tout écrit à partir de son propre tampon matériel. Vous devez définir l' bsoption de la commande dd à chaque fois une valeur différente pour différents appareils.

Basile Starynkevitch
la source
Si rdsk est disponible dans les systèmes Linux? J'ai utilisé dans les systèmes Unix.
KKD
1
Le cache de pages traitera probablement en blocs de 4 Ko quoi que vous fassiez, mais vous pouvez contrôler le nombre d'appels système utilisés par dd pour lire ces 4 Ko. Je suis sûr qu'il y a une taille de lecture au-dessus de laquelle le coût des blocages d'écriture est plus cher que les appels système enregistrés, mais je n'ai aucune idée de l'endroit où se trouve le point idéal.
Inutile
Une taille de bloc de quelques Mo est meilleure que la 512B par défaut, mais lorsque j'ai évalué cela, j'ai trouvé que c'étaitcat aussi bien (pour le transfert de système de fichiers à système de fichiers, le bloc à bloc direct peut avoir des caractéristiques de performances différentes). Cependant, la différence n'était pas dramatique en tout cas.
Gilles 'SO- arrête d'être méchant'
1
Fait intéressant, dans macOS (certifié SUS, btw), il est plus rapide à utiliser/dev/rdiskX comme cible lors de l'exécution dd.
adib
1
au cas où vous vous demanderiez ce qui se passe (comme je l'ai fait), ajoutez également status=progressqui imprimera la progression de l'opération.
Aleksander Lech
17

Il y a des années dans Unix-land ddétait le moyen requis pour copier un périphérique bloc. Cela s'est poursuivi en tant que connaissance culte du fret même si (sur les systèmes Linux, au moins) catest presque toujours plus rapide que dd.

Cependant, même dans l'histoire, une taille de bloc décente a contribué à réduire le nombre d'appels système (lents), étant donné que chaque appel système a déclenché une opération d'E / S. La taille de bloc par défaut est de 512 octets (un secteur de disque). La collecte de plusieurs blocs de disques en une seule lecture était - et est - également acceptable. Cet exemple utilise une taille de bloc de 32 Mo:

dd bs=$((512*2048*32)) if=/dev/source of=/dev/target

Sur les systèmes Linux actuels, cependant, les disques peuvent être copiés plus efficacement avec un simple cat

cat /dev/source >/dev/target

(Comme indiqué dans les commentaires sur votre question, il pvpeut être remplacé catet vous donnera une indication des progrès et du débit.)

roaima
la source
3
Plus précisément, la raison pour laquelle dd devait être utilisé était un bogue dans GNU cp et un bogue dans le noyau Linux au début des années 90. Les raisons d'utiliser dd sur les systèmes Unix historiques étaient très différentes, et vouloir copier un périphérique bloc entier était une chose inhabituelle.
Random832
1
@ Random832 vouloir copier un disque entier aurait été inhabituel, mais je me souviens avoir eu besoin de copier des partitions (grandes - 150 ou même 200 Mo)
roaima
3
(Les spécificités des bogues: le noyau a signalé des tailles d’utilisation du disque incorrectes [ce qui a amené cp à conclure que chaque fichier source était un fichier clairsemé], et cp n’a pas mis à zéro les blocs lors de la copie d’un fichier clairsemé vers une destination de périphérique. bloc dans votre source aurait toutes les ordures qui se
trouvaient
J'adore ce genre de réponse. Merci pour l'info. Voici votre mise à jour.
catbadger
7

Généralement, ddpeut être évité en faveur de certaines alternatives. Il y a plusieurs bonnes raisons d'utiliser GNU à la ddrescueplace. Dans Ubuntu, vous pouvez l'installer avec:

sudo apt-get install gddrescue

et tout simplement simple ddrescueà utiliser. Notez que différemment du nom du package, l'exécutable n'a pas l'initiale g.

Son utilisation est aussi simple que:

ddrescue inputFile outputFile logFile

Le fichier journal (nommé quel que soit votre choix) vous permet de suspendre / arrêter et redémarrer, sans refaire le travail précédent, ce qui est utile lors de la création de gros clones ou de la récupération de disques. Par défaut, il affiche la progression, la vitesse de copie actuelle, la vitesse de copie moyenne et le nombre de blocs défectueux trouvés.

Il utilise des valeurs par défaut raisonnables pour la taille des blocs, donc la vitesse de copie est toujours aussi rapide que le périphérique peut le gérer, du moins d'après mon expérience (j'ai cloné plusieurs centaines de disques avec lui, toutes tailles et types).

Souvent, les disques qui commencent à tomber en panne ont des problèmes de vitesse tels que des correctifs occasionnels de lenteur, de faible vitesse moyenne, de longues pauses soudaines (secteurs défectueux) ou des réinitialisations complètes (graves erreurs de surface). ddrescuepeut vous aider à identifier tout ce qui précède et à redémarrer votre clone (à condition que vous ayez spécifié un fichier journal) même si votre lecteur se réinitialise.

mec technique
la source
6

Très belle question. L'interface brute est implémentée sur certains systèmes Unix (tru64, hpux, solaris) mais pas sur linux. L'interface brute accélère le transfert car les E / S Unix sont ignorées. L'interface de bloc ( /dev/dskou /dev/disk) est plus lente car elle utilise le système d'E / S Unix. Pour accélérer dd(gnu dd peut) utilisez bs=30Mou bs=20Mselon votre matériel. La réponse courte est: NON, elle n'est pas mise en œuvre, du moins pour autant que je sache. J'utilise linux depuis les temps anciens de la version 2.2 du noyau et je n'ai jamais vu rdskutilisé sous unix.

elbarna
la source
5
Pourquoi proposez-vous une taille de bloc qui n'est pas une puissance de deux?
Basile Starynkevitch
2
@Basile, un multiple de la taille du bloc de disque est suffisant, donc 20 Mo suffiraient.
roaima