dd : Comment calculer la taille de bloc optimale ?

Question

Comment calculer la taille optimale des blocs lors de l'exécution d'un programme de gestion des blocs ? dd ? J'ai fait quelques recherches à ce sujet et je n'ai rien trouvé qui suggère comment cela pourrait être accompli.

J'ai l'impression qu'une taille de bloc plus importante se traduirait par une plus grande rapidité d'exécution. dd ... est-ce vrai ?

Je suis sur le point de dd deux disques durs Hitachi identiques de 500 Go fonctionnant à 7200 tr/min sur une machine équipée d'un Intel Core i3 et de 4 Go de RAM DDR3 1333mhz. J'essaie donc de déterminer la taille de bloc à utiliser. (Je vais démarrer Ubuntu 10.10 x86 à partir d'un lecteur flash, et l'exécuter à partir de cela).

Answer 1

La taille optimale des blocs dépend de plusieurs facteurs, dont le système d'exploitation (et sa version), ainsi que les différents bus et disques matériels concernés. Plusieurs systèmes de type Unix (y compris Linux et au moins certaines versions de BSD) définissent la taille de bloc optimale en fonction du système d'exploitation. st_blksize membre de la struct stat qui donne ce que le noyau pense être la taille optimale des blocs :

#include <sys/stat.h>
#include <stdio.h>

int main(void)
{
    struct stat stats;

    if (!stat("/", &stats))
    {
        printf("%u\n", stats.st_blksize);
    }
}

Le meilleur moyen est peut-être d'expérimenter : copiez un gigaoctet avec différentes tailles de blocs et chronométrez le tout. (N'oubliez pas d'effacer les caches des tampons du noyau avant chaque exécution : echo 3 > /proc/sys/vm/drop_caches ).

Cependant, en règle générale, j'ai constaté qu'une taille de bloc suffisamment grande permet de laisser dd font un bon travail, et les différences entre, disons, 64 KiB et 1 MiB sont mineures, comparées à 4 KiB contre 64 KiB. (Bien que, il faut l'admettre, cela fait un moment que je n'ai pas fait cela. J'utilise un mebibyte par défaut maintenant, ou je laisse juste dd choisissez la taille).

Answer 2

J'ai trouvé que la taille de bloc optimale était de 8 Mo (égale à la mémoire cache du disque). J'avais besoin de nettoyer (certains disent : laver) l'espace vide d'un disque avant d'en créer une image compressée. J'ai utilisé :

cd /media/DiskToWash/
dd if=/dev/zero of=zero bs=8M; rm zero

J'ai expérimenté des valeurs allant de 4K à 100M.

Après avoir laissé dd fonctionner pendant un moment, je l'ai tué (Ctrl+C) et j'ai lu la sortie :

36+0 records in
36+0 records out
301989888 bytes (302 MB) copied, 15.8341 s, 19.1 MB/s

Comme dd affiche le taux d'entrée/sortie (19,1 Mo/s dans ce cas), il est facile de voir si la valeur que vous avez choisie est plus performante que la précédente ou moins performante.

Mes scores :

bs=   I/O rate
---------------
4K    13.5 MB/s
64K   18.3 MB/s
8M    19.1 MB/s <--- winner!
10M   19.0 MB/s
20M   18.6 MB/s
100M  18.6 MB/s   

Remarque : Pour vérifier la taille de votre cache/tampon de disque, vous pouvez utiliser la commande suivante sudo hdparm -i /dev/sda

Answer 3

Cela dépend totalement du système. Vous devez expérimenter pour trouver la solution optimale. Essayez de commencer avec bs=8388608 . (Comme les disques durs Hitachi semblent avoir un cache de 8MB).

Answer 4

Vous pouvez essayer d'utiliser dd-opt un petit utilitaire que j'ai écrit.

(Améliorations/réflexions bienvenues !)

Answer 5

• pour de meilleures performances, utilisez la plus grande taille de bloc que votre RAM peut accueillir (cela enverra moins d'appels E/S au système d'exploitation).
• pour une meilleure précision et récupération des données, définissez la taille de bloc à la taille de secteur native de l'entrée.

Lorsque dd copie des données avec l'option conv=noerror,sync, toute erreur rencontrée entraîne le remplacement du reste du bloc par des octets nuls. Des blocs de plus grande taille seront copiés plus rapidement, mais chaque fois qu'une erreur est rencontrée, le reste du bloc est ignoré.

source