L'option "bs" de "dd" améliore-t-elle vraiment la vitesse?

Question

De temps en temps, on me dit que pour augmenter la vitesse d'un "dd", je dois soigneusement choisir une "taille de bloc" appropriée.

Même ici, sur ServerFault, quelqu'un d'autre a écrit que " ... la taille de bloc optimale dépend du matériel ... " (iain) ou " ... la taille parfaite dépendra de votre bus système, du contrôleur de disque dur, du lecteur particulier lui-même et des pilotes pour chacun de ces ... " (chris-s)

Comme mon sentiment était un peu différent ( BTW: je pensais que le temps nécessaire pour régler en profondeur le paramètre bs était beaucoup plus élevé que le gain reçu, en termes de gain de temps, et que le la valeur par défaut était raisonnable ), aujourd'hui je viens de passer en revue quelques points de repère rapides et sales.

Afin de réduire les influences extérieures, j'ai décidé de lire:

à partir d'une carte MMC externe
à partir d'une partition interne

et:

avec les systèmes de fichiers associés démontés
envoyer la sortie à/dev/null pour éviter les problèmes liés à la "vitesse d'écriture";
éviter certains problèmes de base de la mise en cache du disque dur, au moins lors de l'implication du disque dur.

Dans le tableau suivant, j'ai rapporté mes résultats, en lisant 1 Go de données avec différentes valeurs de "bs" (, vous pouvez trouver les chiffres bruts à la fin de ce message ):

enter image description here

Fondamentalement, il ressort que:

MMC: avec un bs = 4 (oui! 4 octets), j'ai atteint un débit de 12 Mo/s. Des valeurs pas si éloignées par rapport au maximum 14,2/14,3 que j'ai obtenues de bs = 5 et plus;
Disque dur: avec un bs = 10 j'ai atteint 30 Mo/s. Sûrement inférieur au 95,3 Mo obtenu avec le bs par défaut = 512 mais ... significatif également.

En outre, il était très clair que le temps sys du processeur était inversement proportionnel à la valeur bs (mais cela semble raisonnable, car plus le bs est bas, plus le nombre d'appels sys générés par dd est élevé).

Cela dit, maintenant la question: quelqu'un peut-il expliquer (un pirate du noyau?) Quels sont les principaux composants/systèmes impliqués dans un tel débit, et si cela vaut vraiment la peine de spécifier un bs supérieur à la valeur par défaut?

Boîtier MMC - chiffres bruts

bs = 1M

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1M count=1000 1000+0 record dentro 1000+0 record fuori 1048576000 byte (1,0 GB) copiati, 74,1239 s, 14,1 MB/s real 1m14.126s user 0m0.008s sys 0m1.588s

bs = 1k

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1k count=1000000 1000000+0 record dentro 1000000+0 record fuori 1024000000 byte (1,0 GB) copiati, 72,7795 s, 14,1 MB/s real 1m12.782s user 0m0.244s sys 0m2.092s

bs = 512

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=512 count=2000000 2000000+0 record dentro 2000000+0 record fuori 1024000000 byte (1,0 GB) copiati, 72,867 s, 14,1 MB/s real 1m12.869s user 0m0.324s sys 0m2.620s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=10 count=100000000 100000000+0 record dentro 100000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 70,1662 s, 14,3 MB/s real 1m10.169s user 0m6.272s sys 0m28.712s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=5 count=200000000 200000000+0 record dentro 200000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 70,415 s, 14,2 MB/s real 1m10.417s user 0m11.604s sys 0m55.984s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=4 count=250000000 250000000+0 record dentro 250000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 80,9114 s, 12,4 MB/s real 1m20.914s user 0m14.436s sys 1m6.236s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=2 count=500000000 500000000+0 record dentro 500000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 161,974 s, 6,2 MB/s real 2m41.976s user 0m28.220s sys 2m13.292s

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1 count=1000000000 1000000000+0 record dentro 1000000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 325,316 s, 3,1 MB/s real 5m25.318s user 0m56.212s sys 4m28.176s

Boîtier HDD - chiffres bruts

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1 count=1000000000 1000000000+0 record dentro 1000000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 341,461 s, 2,9 MB/s real 5m41.463s user 0m56.000s sys 4m44.340s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=2 count=500000000 500000000+0 record dentro 500000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 164,072 s, 6,1 MB/s real 2m44.074s user 0m28.584s sys 2m14.628s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=4 count=250000000 250000000+0 record dentro 250000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 81,471 s, 12,3 MB/s real 1m21.473s user 0m14.824s sys 1m6.416s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=5 count=200000000 200000000+0 record dentro 200000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 66,0327 s, 15,1 MB/s real 1m6.035s user 0m11.176s sys 0m54.668s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=10 count=100000000 100000000+0 record dentro 100000000+0 record fuori 1000000000 byte (1,0 GB) copiati, 33,4151 s, 29,9 MB/s real 0m33.417s user 0m5.692s sys 0m27.624s

bs = 512 (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=512 count=2000000 skip=6000000 2000000+0 record dentro 2000000+0 record fuori 1024000000 byte (1,0 GB) copiati, 10,7437 s, 95,3 MB/s real 0m10.746s user 0m0.360s sys 0m2.428s

bs = 1k (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1k count=1000000 skip=6000000 1000000+0 record dentro 1000000+0 record fuori 1024000000 byte (1,0 GB) copiati, 10,6561 s, 96,1 MB/s real 0m10.658s user 0m0.164s sys 0m1.772s

bs = 1k (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1M count=1000 skip=7000 1000+0 record dentro 1000+0 record fuori 1048576000 byte (1,0 GB) copiati, 10,7391 s, 97,6 MB/s real 0m10.792s user 0m0.008s sys 0m1.144s

user313114 · Answer

Ce que vous avez fait n'est qu'un test de vitesse de lecture. si vous copiez réellement des blocs sur un autre appareil, vous avez des pauses dans la lecture pendant que l'autre appareil accepte les données que vous souhaitez écrire, lorsque cela se produit, vous pouvez rencontrer des problèmes de latence de rotation sur l'appareil de lecture (s'il s'agit d'un disque dur), etc. il est souvent beaucoup plus rapide de lire des morceaux de 1 M sur le disque dur, car vous vous heurtez moins souvent à la latence de rotation de cette façon.

Je sais que lorsque je suis copie disques durs, j'obtiens un débit plus rapide en spécifiant bs=1M qu'en utilisant bs=4k ou la valeur par défaut. Je parle d'améliorations de vitesse de 30 à 300 pour cent. Il n'est pas nécessaire de le régler au mieux, sauf si c'est tout ce que vous faites tous les jours. mais choisir quelque chose de mieux que la valeur par défaut peut réduire le temps d'exécution.

Lorsque vous l'utilisez pour de vrai, essayez quelques numéros différents et envoyez le processus dd un SIGUSR1 signal pour qu'il émette un rapport de situation afin que vous puissiez voir comment ça se passe.

✗ killall -SIGUSR1 dd 1811+1 records in 1811+1 records out 1899528192 bytes (1.9 GB, 1.8 GiB) copied, 468.633 s, 4.1 MB/s

Matthew Ife · Answer

En ce qui concerne le disque dur interne, au moins - lorsque vous lisez à partir de l'appareil, la couche de bloc au moins doit récupérer un secteur de 512 octets.

Ainsi, lorsque vous gérez une lecture de 1 octet, vous n'avez vraiment lu qu'à partir du disque sur la récupération d'octets alignés sur le secteur. Les 511 fois restantes sont servies par cache.

Vous pouvez le prouver comme suit, dans cet exemple sdb est un disque intéressant:

# grep sdb /proc/diskstats 8 16 sdb 767 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359 ... # dd if=/dev/sdb of=/dev/null bs=1 count=512 512+0 records in 512+0 records out 512 bytes (512 B) copied, 0.0371715 s, 13.8 kB/s # grep sedb /proc/diskstats 8 16 sdb 768 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359 ...

La quatrième colonne (qui compte les lectures) indique qu'une seule lecture s'est produite, malgré le fait que vous ayez demandé des lectures de 1 octet. Il s'agit d'un comportement attendu car ce périphérique (un disque SATA 2) doit au minimum retourner sa taille de secteur. Le noyau met simplement en cache tout le secteur.

Le facteur le plus important en jeu dans ces demandes de taille est la surcharge de l'émission d'un appel système pour une lecture ou une écriture. En fait, l'émission de l'appel pour <512 est inefficace. Les lectures très volumineuses nécessitent moins d'appels système au prix de plus de mémoire utilisée pour le faire.

4096 est généralement un nombre "sûr" pour la lecture car:

Lors de la lecture avec mise en cache (par défaut), une page fait 4k. Remplir une page avec <4k lectures est plus compliqué que de conserver la même taille de lecture et de page.
La plupart des tailles de bloc du système de fichiers sont définies sur 4k.
Ce n'est pas un nombre suffisamment petit (peut-être pour les SSD maintenant) pour provoquer une surcharge d'appels système, mais pas un nombre assez important pour consommer beaucoup de mémoire.