Pourquoi le passage de 'dd' par gzip est-il tellement plus rapide qu'une copie directe ?

Un peu tard, mais puis-je ajouter...

Lors d'un entretien, on m'a demandé une fois Quelle serait la méthode la plus rapide pour cloner des données bit à bit ? et, bien sûr, a répondu en utilisant dd o dc3dd ( Financé par le DoD ). L'enquêteur a confirmé que la tuyauterie dd a dd est plus efficace, car elle permet simplement lecture/écriture simultanées ou en termes de programmeur stdin/stdout Ainsi, la vitesse d'écriture est doublée et le temps de transfert est réduit de moitié.

dc3dd verb=on if=/media/backup.img | dc3dd of=/dev/sdb

Cong est correct. Vous diffusez les blocs à partir du disque sans les compresser vers un hôte distant. Votre interface réseau, votre réseau et votre serveur distant sont les limites. Vous devez d'abord améliorer les performances de DD. En spécifiant un paramètre bs= qui s'aligne sur la mémoire tampon du disque, vous obtiendrez les meilleures performances du disque. Disons bs=32M par exemple. Cela remplira alors le tampon de gzip à un taux de ligne sata ou sas directement à partir du tampon du disque. Le disque sera plus enclin au transfert séquentiel donnant un meilleur rendement. Gzip va compresser les données dans le flux et les envoyer à votre emplacement. Si vous utilisez NFS, cela permettra à la transmission NFS d'être minimale. Si vous utilisez SSH, vous encurerez l'encapsulation SSH et la surcharge de cryptage. Si vous utilisez netcat, vous n'avez pas de surcharge de cryptage.

Je suppose ici que la "vitesse de transfert" à laquelle vous faites référence est rapportée par dd . Cela a en fait du sens, car dd transfère en fait 10 fois plus de données par seconde. ! Cependant, dd n'est pas transféré sur le réseau - cette tâche est prise en charge par le système de gestion de l'information. gzip processus.

Un peu de contexte : gzip consommera les données de son tube d'entrée aussi vite qu'il pourra vider sa mémoire tampon interne. La vitesse à laquelle gzip Le vidage de la mémoire tampon dépend de plusieurs facteurs :

• La bande passante d'écriture E/S (qui est goulotée par le réseau, et qui est restée constante).
• La bande passante de lecture des E/S (qui sera bien supérieure à 1 Mo/s pour la lecture d'un disque local sur une machine moderne, et qui n'est donc pas un goulot d'étranglement probable).
• son taux de compression (qui, d'après votre accélération de 10 fois, doit être d'environ 10 %, ce qui indique que vous comprimez un texte très répétitif, comme un fichier journal ou du XML).

Donc dans ce cas, le réseau peut gérer 100kB/s, et gzip compresse les données dans un rapport de 10:1 (et n'est pas bloqué par le CPU). Cela signifie que pendant qu'il sort 100kB/s, gzip puede consommer 1MB/s, et le taux de consommation est de l'ordre de dd peut voir.