Existe-t-il un moyen de déterminer la valeur optimale pour le paramètre bs à dd?
À l'occasion, j'ai vu des commentaires en ligne du type "assurez-vous de définir" bs = "car la valeur par défaut prendra trop de temps", et mes propres expériences extrêmement non scientifiques de ", eh bien, cela semblait prendre plus de temps que cet autre la semaine dernière "semblent le confirmer. Donc, chaque fois que j'utilise "dd" (généralement dans la plage de 1 à 2 Go), je m'assure de spécifier le paramètre octets. Environ la moitié du temps, j'utilise la valeur spécifiée dans le guide en ligne à partir duquel je copie; le reste du temps, je choisirai un nombre logique dans la liste `` fdisk -l '' pour ce que je suppose être le support le plus lent (par exemple, la carte SD sur laquelle j'écris).
Pour une situation donnée (type de support, taille des bus ou tout autre élément important), existe-t-il un moyen de déterminer une "meilleure" valeur? Est-il facile à déterminer? Sinon, existe-t-il un moyen facile d'obtenir 90 à 95% du chemin? Ou "choisissez simplement quelque chose de plus grand que 512", même la bonne réponse?
J'ai pensé essayer l'expérience moi-même, mais (en plus d'être beaucoup de travail), je ne sais pas quels facteurs ont un impact sur la réponse, donc je ne sais pas comment concevoir une bonne expérience.
dd date de l'époque où il était nécessaire de traduire les anciennes bandes IBM mainframe, et la taille du bloc devait correspondre à celle utilisée pour écrire la bande ou les blocs de données seraient sautés ou tronqués. (Les bandes 9 pistes étaient capricieuses. Soyez heureux qu'elles soient mortes depuis longtemps.) De nos jours, la taille de bloc devrait être un multiple de la taille du secteur de l'appareil (généralement 4 Ko, mais sur des disques très récents, elle peut être beaucoup plus grande et sur un très petit pouce) les disques peuvent être plus petits, mais 4KB est un juste milieu raisonnable malgré tout) et plus le meilleur est pour les performances. J'utilise souvent des blocs de 1 Mo avec des disques durs. (Nous avons aussi beaucoup plus de mémoire à jeter ces jours-ci.)
Il n'y a qu'une seule façon de déterminer la taille de bloc optimale, et c'est une référence. Je viens de faire une référence rapide. La machine de test est un PC exécutant Debian GNU/Linux, avec le noyau 2.6.32 et coreutils 8.5. Les deux systèmes de fichiers concernés sont ext3 sur des volumes LVM sur une partition de disque dur. Le fichier source est de 2 Go (2040000kB pour être précis). La mise en cache et la mise en mémoire tampon sont activées. Avant chaque exécution, j'ai vidé le cache avec sync; echo 1 >|/proc/sys/vm/drop_caches. Les temps d'exécution n'incluent pas un sync final pour vider les tampons; la finale sync prend de l'ordre de 1 seconde.
Les exécutions same étaient des copies sur le même système de fichiers; les exécutions diff étaient des copies vers un système de fichiers sur un autre disque dur. Par souci de cohérence, les heures signalées sont les heures d'horloge murale obtenues avec l'utilitaire time, en secondes. Je n'ai exécuté chaque commande qu'une seule fois, donc je ne sais pas combien il y a de variation dans le timing.
same diff
t (s) t (s)
dd bs=64M 71.1 51.3
dd bs=1M 73.9 41.8
dd bs=4k 79.6 48.5
dd bs=512 85.3 48.9
cat 76.2 41.7
cp 77.8 45.3
Conclusion: Une grande taille de bloc (plusieurs mégaoctets) aide, mais pas de façon spectaculaire (beaucoup moins que ce que j'attendais pour des copies sur le même lecteur). Et cat et cp ne fonctionnent pas si mal. Avec ces chiffres, je ne trouve pas que dd vaille la peine. Allez avec cat!
Je suis d'accord avec le geekosaur que la taille doit être un multiple de la taille du bloc, qui est souvent 4K.
Si vous voulez trouver la taille de bloc stat -c "%o" filename Est probablement l'option la plus simple.
Mais disons que vous faites dd bs=4K, Cela signifie qu'il fait read(4096); write(4096); read(4096); write(4096)...
Chaque appel système implique un changement de contexte, ce qui implique une surcharge, et selon le planificateur d'E/S, les lectures avec des écritures entrecoupées peuvent amener le disque à effectuer de nombreuses recherches. (Probablement pas un problème majeur avec le planificateur Linux, mais néanmoins quelque chose à penser.)
Donc, si vous faites bs=8K, Vous autorisez le disque à lire deux blocs à la fois, qui sont probablement proches l'un de l'autre sur le disque, avant de chercher ailleurs pour faire l'écriture (ou pour réparer les E/S pour un autre processus ).
Selon cette logique, bs=16K Est encore mieux, etc.
Donc, ce que j'aimerais savoir, c'est s'il y a une limite supérieure où les performances commencent à empirer, ou si elles ne sont limitées que par la mémoire.
Comme le dit Gilles, vous pouvez déterminer le paramètre optimal pour l'option bs à dd par analyse comparative. Cependant, cela soulève la question: comment pouvez-vous facilement comparer ce paramètre?
Ma réponse provisoire à cette question est: utilisez dd-opt , l'utilitaire sur lequel j'ai récemment commencé à travailler pour résoudre précisément ce problème :)
J'ai optimisé pour le lecteur sdcard usb2.0 qui semble fonctionner mieux à bs=10M. J'ai essayé 4k, sur jusqu'à 16M, après 8-10M aucune amélioration. Vous pouvez voir comment la mesure du taux de transfert se dégrade ... très probablement en raison du chargement des tampons sur l'appareil, puis de l'attente du transfert de l'appareil sur le support réel.
angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s