Existe-t-il un moyen de déterminer la valeur optimale du paramètre bs sur 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 ", cela semblait prendre plus de temps que cet autre le temps passé la semaine dernière "semble le confirmer. Ainsi, 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 bytes. Environ la moitié du temps que j’utilise la valeur spécifiée dans le guide en ligne à partir duquel je copie; le reste du temps, je choisirai un nombre qui ait du sens dans la liste 'fdisk -l' pour ce que je suppose être le support le plus lent (par exemple, la carte SD sur laquelle je vous écris).

Pour une situation donnée (type de support, taille du bus ou autre chose qui compte), existe-t-il un moyen de déterminer la "meilleure" valeur? Est-ce facile à déterminer? Sinon, y a-t-il un moyen facile d'obtenir 90 à 95% du trajet? Ou est-ce que "choisissez juste quelque chose plus grand que 512" est même la bonne réponse?

J'ai pensé essayer l'expérience moi-même, mais (en plus de mon travail), je ne sais pas quels facteurs ont un impact sur la réponse, je ne sais donc pas comment concevoir une bonne expérience.

dddate de l'époque où il était nécessaire de traduire les anciennes bandes d'ordinateurs centraux IBM et que la taille du bloc devait correspondre à celle utilisée pour écrire la bande, sinon les blocs de données seraient ignorés ou tronqués. (Les cassettes 9 pistes étaient capricieux. Soyez heureux qu'elles soient mortes depuis longtemps.) Ces jours-ci, la taille du bloc devrait être un multiple de la taille du secteur du périphérique (généralement 4Ko, mais sur des disques très récents, ils peuvent être beaucoup plus grands et très petits. les disques peuvent être plus petits, mais 4 Ko est un terrain d’entente raisonnable, peu importe) et plus grand est le meilleur pour la performance. J'utilise souvent des tailles de bloc de 1 Mo avec des disques durs. (Nous avons beaucoup plus de mémoire à jeter ces jours-ci aussi.)

Il n'y a qu'un moyen de déterminer la taille optimale du bloc, et c'est un point de repère. Je viens de faire un repère rapide. La machine de test est un PC sous Debian GNU / Linux, avec le noyau 2.6.32 et coreutils 8.5. Les deux systèmes de fichiers impliqués sont ext3 sur des volumes LVM sur une partition de disque dur. Le fichier source est de 2 Go (2040000k pour être précis). La mise en cache et la mise en mémoire tampon sont activées. Avant chaque course, j'ai vidé le cache avec sync; echo 1 >|/proc/sys/vm/drop_caches. Les temps d'exécution n'incluent pas de finale syncpour vider les tampons; la finale syncprend environ 1 seconde. Les sameexécutions étaient des copies sur le même système de fichiers; les diffexécutions étaient des copies sur un système de fichiers sur un disque dur différent. Par souci de cohérence, les temps rapportés sont les temps d’horloge murale obtenus avectimeutilité, en secondes. Je n'ai exécuté qu'une seule fois chaque commande, donc je ne sais pas à quel point il y a de la variance dans le timing.

             same   diff
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 taille de bloc importante (plusieurs mégaoctets) peut aider, mais pas de façon spectaculaire (beaucoup moins que ce à quoi je m'attendais pour les copies avec un même lecteur). Et catet cpne performez pas si mal. Avec ces chiffres, je ne trouve pas la ddpeine de s’inquiéter. Allez avec cat!

Je suis d'accord avec geekosaur que la taille devrait être un multiple de la taille du bloc, qui est souvent 4K.

Si vous voulez trouver la taille du bloc, stat -c "%o" filenamec'est probablement l'option la plus simple.

Mais dites que vous faites dd bs=4K, cela signifie que ça le fait read(4096); write(4096); read(4096); write(4096)...

Chaque appel système implique un changement de contexte, ce qui implique une surcharge et, en fonction du planificateur d'E / S, les lectures avec des écritures intercalées peuvent amener le disque à effectuer de nombreuses recherches. (Ce n’est probablement pas un problème majeur avec le planificateur Linux, mais il faut quand même réfléchir.)

Ainsi, si vous le 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 un autre moyen d'effectuer l'écriture (ou de gérer les E / S pour un autre processus).

Par cette logique, bs=16Kc'est encore mieux, etc.

Ce que j'aimerais savoir, c'est s'il existe une limite supérieure à partir de laquelle les performances commencent à se dégrader ou si elles ne sont limitées que par la mémoire.

Comme Gilles le dit, vous pouvez déterminer le paramètre optimal pour l' option bs à dd en procédant à une analyse comparative. Cela pose cependant la question suivante: comment comparer facilement ce paramètre?

Ma tentative de réponse à cette question est la suivante: 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 de carte SD usb2.0 qui semble fonctionner le mieux bs=10M. J'ai essayé 4k, sur 16M, après 8-10M sans amélioration. Vous pouvez voir comment la mesure du taux de transfert se dégrade ... probablement en raison du chargement des mémoires tampons sur le périphérique, puis de l'attente du transfert du périphérique 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