J'ai 200 Go d'espace disque libre, 16 Go de RAM (dont ~ 1 Go sont occupés par le bureau et le noyau) et 6 Go de swap.
J'ai un SSD externe de 240 Go, avec 70 Go utilisés 1 et le reste libre, que je dois sauvegarder sur mon disque.
Normalement, je voudrais dd if=/dev/sdb of=Desktop/disk.img
d'abord le disque, puis le compresser, mais créer l'image en premier n'est pas une option car cela nécessiterait beaucoup plus d'espace disque que moi, même si l'étape de compression entraînera l'écrasement de l'espace libre de sorte que le l'archive finale peut facilement tenir sur mon disque.
dd
écrit dans STDOUT par défaut, et gzip
peut lire depuis STDIN, donc en théorie je peux écrire dd if=/dev/sdb | gzip -9 -
, mais il gzip
faut beaucoup plus de temps pour lire les octets que ce qui dd
peut les produire.
De man pipe
:
Les données écrites à l'extrémité d'écriture du canal sont mises en mémoire tampon par le noyau jusqu'à ce qu'elles soient lues à l'extrémité de lecture du canal.
Je visualise un |
comme étant un vrai tube - une application insérant des données et l'autre retirant les données de la file d'attente du tube le plus rapidement possible.
Que se passe-t-il lorsque le programme sur le côté gauche écrit plus de données plus rapidement que l'autre côté du tuyau peut espérer les traiter? Cela entraînera-t-il une utilisation extrême de la mémoire ou des échanges, ou le noyau essaiera-t-il de créer une FIFO sur le disque, remplissant ainsi le disque? Ou échouera-t-il simplement SIGPIPE Broken pipe
si le tampon est trop volumineux?
Fondamentalement, cela se résume à deux questions:
- Quelles sont les implications et les résultats de l'introduction de plus de données dans un tube que ce qui est lu à la fois?
- Quel est le moyen fiable de compresser un flux de données sur le disque sans placer l'intégralité du flux de données non compressé sur le disque?
Remarque 1: je ne peux pas simplement copier exactement les 70 premiers Go utilisés et m'attendre à obtenir un système ou un système de fichiers fonctionnel, en raison de la fragmentation et d'autres choses qui nécessiteront l'intégralité du contenu.
lzop
lieu de gzip
; il se comprime beaucoup plus rapidement avec seulement un taux de compression légèrement inférieur. Je le trouve idéal pour les images de disque où la vitesse de compression peut être un véritable goulot d'étranglement.