Forum Linux.général [résolu] Création image disque en "ignorant" l'espace inutilisé

Posté par  . Licence CC By‑SA.
Étiquettes :
5
29
juin
2025

Bonjour,

Je suis en train de cloner un disque USB de 750 GB (en Ext4), dont environ 40 sont utilisés.
Pour l'instant je suis parti sur :

zerofree /dev/sdf1
dd if=/dev/sdf bs=32M | gzip -c > /foo/bar/my_image.dd.gz

En continuant comme ça, j'en aurais pour la journée (6 heures à 70 MB / seconde), alors qu'en théorie il y aurait moyen de faire ça en 20 minutes…

Est-ce que quelqu'un connaîtrait un utilitaire magique qui remplace à la volée l'espace inutilisé par des zéros ?

Ça accélérerait pas mal la création de l'image du disque.

Edit suite aux réponses en commentaire :

partclone

Partclone répond au besoin, de 6 heures je suis passé à 15 minutes, par contre le format de sortie est spécifique.

partclone.ext4 -c -d -s /dev/sdf1 -o disque.partclone

Comme attendu, le fichier de sortie fait 40.1 GB (soit l'espace utilisé sur le disque)
test refait plus tard, voir plus bas

partclone + gzip

En restaurant l'image et en zippant :

partclone.ext4 -c -d -s /dev/sdf1 | partclone.restore -d -s - | gzip -c > disque.img.gz

Avantage : on peut restaurer l'image en ayant juste gunzip et dd.

Par contre, on passe à un peu plus de 55 minutes, dû probablement à la compression monothread (sur CPU Intel core i5-14400F avec disque NVMe tenant 2.5 GB par seconde en écriture).
Pour un disque de 750.2 GB dont 40.1 GB utilisé, on arrive à un fichier de 39.2 GB donc plutôt bien.

partclone + pigz

partclone.ext4 -c -d -s /dev/sdf1 | partclone.restore -d -s - | pigz -c > disque.img.gz

Le fichier de sortie est passé de 39.2 à 39.3 GB, différence qui reste négligeable.
Par contre, la durée de clonage est passée à 13 minutes 16 secondes, ce qui est même plus rapide que partclone seul. A éviter en période de canicule (température CPU à 80°C)
Une explication possible serait que le test avec partclone seul se faisait en direction d'un disque dur SATA (à plateau) un peu plus lent (175 MB par secondes).

FSArchiver

fsarchiver -j10 savefs disque.fsa /dev/sdf1

(j10 à adapter en fonction du nombre de cœurs du CPU)

Ça fait presque peur, 9 minutes 32 secondes pour cloner le disque (sortie de 38.2 GB). À noter que le CPU a nettement moins chauffé qu'avec pigz (CPU à 48°C). Reste le problème du format de fichier de sortie qui est spécifique à fsarchiver.

partclone (le retour)

Ça m'étonnait un peu que partclone + pigz soit plus rapide que partclone seul, donc j'ai refait le test en dirigeant vers le NVMe.
La durée passe à 7 minutes 44 (soit 88 MB/secondes ce qui est plus rapide que le test de performances de gnome…)

Conclusion

Je vais en rester là vu que le problème est résolu, à long terme je pense rester sur la solution partclone + pigz pour garder un format de sortie "standard".

Merci à Éric et Cyril pour votre aide.

NB: dire qu'au final, ça aura pris 6 heures…

  • # clonezilla ?

    Posté par  (site web personnel) . Évalué à 5 (+4/-0).

    Il me semble que clonezilla ne copie que le nécessaire. La doc indique qu'il utilise le logiciel partclone en couche basse.

    • [^] # Re: clonezilla ?

      Posté par  . Évalué à 4 (+3/-0).

      merci, partclone semble correspondre à ce que j'ai besoin.

      partclone.ext4 -c -d -s /dev/sdf1 | gzip -c > image.partclone.gz

      A priori, il annonce un quart d'heure, ce qui est nettement mieux.
      Bon par contre, par rapport à dd, on perd le côté "image standard", mais bon pas le choix…

      Les vrais naviguent en -42

  • # Quel est le cas d'usage ?

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Tu parles de cloner un disque, mais pas trop de ce que tu veux en faire plus tard.

    Est-ce que c'est pour remplacer à l'identique en cas de problème ? Pour déployer sur une autre machine avec la même capacité ? Sauvegarder le système de fichiers plutôt que le disque ? Est-ce pour une opération ponctuelle ou récurrente ? Par exemple, en fonction des besoins, une table de partitions n'est pas forcément pertinente.

    Quoi qu'il en soit, quand il s'agit de créer une image disque comprimée, zerofree peut être ton ami.

    (Sur des images spécifiques générées pour des clients, entre 3 et 4 Go, plus ou moins remplies, le gain en taille après compression en xz était de l'ordre de 40 %.)

    Sinon, un autre outil pour travailler au niveau du FS : fsarchiver.

    Debian Consultant @ DEBAMAX

    • [^] # Re: Quel est le cas d'usage ?

      Posté par  . Évalué à 2 (+1/-0).

      C'est un disque dur qui était branché sur la télévision pour enregistrer des films de la TNT, les enregistrements sont dans un format propriétaire et chiffrés.. Je compte le réutiliser (temporairement ?) pour autre chose, donc je me fais une sauvegarde pour pouvoir le rebrancher sur la TV plus tard.

      A noter que j'avais déjà transféré les enregistrements de la télé d'un disque à un autre en faisant un dd suivi d'une extension de partition (40 GB vers 750) et que ça s'était bien passé. Donc je ne m'inquiète pas trop de ce côté là.

      Dans le cas qui me concerne aujourd'hui, la meilleur solution semble être l'enregistrement au format partclone pour sa vitesse.
      J'en profite quand même pour voir à plus long terme pour mes images disque, et dans ce cas, je cherche à limiter les dépendances lors de la restauration, d'où le test partclone + conversion au format "image brute compressée", par contre la conversion limite vraiment les performances (je donnerai les chiffres dès que ça sera terminé).

      Il faudra que je teste FSArchiver au passage.

      Les vrais naviguent en -42

      • [^] # Re: Quel est le cas d'usage ?

        Posté par  (site web personnel) . Évalué à 5 (+3/-0).

        Voir pigz et pixz si des cœurs s'ennuient.

        Debian Consultant @ DEBAMAX

        • [^] # Re: Quel est le cas d'usage ?

          Posté par  . Évalué à 2 (+1/-0).

          Bon, ben c'est reparti pour pigz.

          J'ai mis à jour le post il y a quelques minutes avec les résultats.

          Je sens qu'au final, au lieu de passer 6 heures à faire mon clonage, je vais faire 6 heures de benchmark… pas grave.

          Les vrais naviguent en -42

          • [^] # Re: Quel est le cas d'usage ?

            Posté par  . Évalué à 2 (+1/-0).

            ah oui, 13 minutes 16 secondes !
            par contre c'était clairement pas la bonne journée pour rajouter du chauffage dans l'appart.

            coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +80.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 4:        +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 8:        +80.0°C  (high = +80.0°C, crit = +100.0°C)
Core 12:       +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 16:       +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 20:       +77.0°C  (high = +80.0°C, crit = +100.0°C)
Core 24:       +74.0°C  (high = +80.0°C, crit = +100.0°C)
Core 25:       +74.0°C  (high = +80.0°C, crit = +100.0°C)
Core 26:       +74.0°C  (high = +80.0°C, crit = +100.0°C)
Core 27:       +74.0°C  (high = +80.0°C, crit = +100.0°C)

            Les vrais naviguent en -42

            • [^] # Re: Quel est le cas d'usage ?

              Posté par  (site web personnel) . Évalué à 2 (+0/-0).

              Savez-vous combien de filaments étaient lancés ? Avec d'autres logiciels et le choix par défaut, j'ai vu des calculs en lancer plus que de processeurs réellement disponibles. Résultats des courses, les calculs prenaient (beaucoup) plus de temps que nécessaire, et la machine ventilait à fond. Rien qu'en faisant un top, on voyait que la charge système était problématique : 25 à 50% user, 50 à 75% pour le système.

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

              • [^] # Re: Quel est le cas d'usage ?

                Posté par  (site web personnel) . Évalué à 3 (+1/-0).

                Par défaut, pigz et pixz utilisent tous les cœurs disponibles. Respectivement :

                       -p --processes n
              Allow up to n processes (default is the number of online processors)

                et :

                       -p CPUS
           Set the number of CPU cores to use. By default pixz will use the number of cores on the system.

                Debian Consultant @ DEBAMAX

                • [^] # Re: Quel est le cas d'usage ?

                  Posté par  (site web personnel) . Évalué à 2 (+1/-1).

                  Donc mon a priori est que sur ce genre de processeurs, ça va provoquer une perte d’efficacité : thermal throttling + OS qui jongle entre des filaments peu utiles. Me tromperais-je ?

                  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

                  • [^] # Re: Quel est le cas d'usage ?

                    Posté par  . Évalué à 2 (+1/-0).

                    J'ai voulu vérifier cet a priori, vu que le sujet m'intéresse un peu.
                    Bon par contre j'ai encore remis à plus tard ce que j'avais prévu pour ce disque dur…

                    J'ai refait les tests en dirigeant la sortie vers /dev/null pour économiser mon nvme.

                    partclone.ext4 -c -d -s /dev/sdf1 | partclone.restore -d -s - | pigz -p10 -c > /dev/null

                    Pour rappel, la config CPU :

                    • 6 cœurs "performance": architecture Raptor Cove, hyperthreading, 2.5 / 4.7 GHz
                    • 4 cœurs "efficient" : architecture Gracemont, pas d'hyperthreading, perf/MHz plus faible, 1.8 / 3.5 GHz

                    Le test a été fait sur Debian 12 avec le noyau 6.12.30.

                    Ce test a été l'occasion de voir que le scheduler n'est pas du tout optimisé pour ce CPU, par moment sur les tests avec peu de threads, ceux-ci se retrouvent à tourner sur des cœurs Gracemont en turbo à 3.1 GHz alors que les cœurs Raptor Cove se reposent à 800 MHz.
                    Ça vaudra le coup d'investiguer pour voir s'il y a pas moyen d'optimiser les paramètres du scheduler.

                    Pour la petite histoire, j'ai activé les dépôts backports de Debian en espérant justement que le noyau prenne en compte cette architecture hybride. Raté.

                    Pour ce qui est des tests, je les ai fait au moins 2 fois chacun, celui sur 16 threads a été fait 3 fois car le premier test a donné une valeur bizarre. Les autres tests ont été reproduits avec écart de moins de 1%, donc on va dire que ce sera suffisamment fiable.

                    Pendant ces tests, l'ordinateur ne faisait rien d'autre.
                    Entre deux tests, j'ai laissé le CPU refroidir jusqu'à 45 °C.

                    Pour la faire courte, les meilleurs performances ont été obtenues avec 12 threads. Le CPU est monté à 80°C voire ponctuellement à 84°C dans toutes les configurations, donc je doute que le thermal throttling ait été plus marqué sur un test qu'un autre.
                    Par contre, effectivement, même si ça ne joue pas à grand chose, les meilleurs performances ont été obtenues pour 12 threads, et qu'à partir de 6 cœurs le gain est négligeable.

                    threads durée
                    1 00:38:08
                    1 00:38:14
                    2 00:21:32
                    2 00:21:26
                    4 00:15:00
                    4 00:15:02
                    6 00:12:50
                    6 00:12:54
                    8 00:12:02
                    8 00:12:06
                    10 00:11:58
                    10 00:12:00
                    12 00:11:44
                    12 00:11:50
                    14 00:12:02
                    14 00:12:04
                    16 00:12:56
                    16 00:13:00
                    16 00:13:50

                    Maintenant on sait.

                    Les vrais naviguent en -42

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.