Journal Du balai avec la commande gdu

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
14
20
sept.
2025

Un système informatique, c'est comme un logement, on a tendance à y accumuler au fil des années et décennies des choses inutiles jusqu'à ne plus savoir ce qu'on a. De temps en temps, il faut faire du tri et le ménage. On a donc tous dans notre pharmacopée quelques commandes ou applications en cas de congestion : à base de df, du, ncdu, etc. Et au niveau graphique, j'aime bien QDirStat.

Je suis tombé récemment sur un article du blog "Le Geek Heureux" dédié à la commande ncdu, mais quelqu'un recommandait en commentaire gdu, plus rapide. C'est écrit en Go, donc Go Disk Usage. Il est annoncé comme étant très rapide en particulier avec les SSD, où son fonctionnement parallèle serait optimum (du point de vue parallélisme, je ne sais pas ce qui diffère avec un disque dur, qu'en pensez-vous ?). Il est empaqueté pour de nombreuses distributions, et effectivement il est rapide. Il analyse mon home en moins d'une seconde. L'interface interactive dans le terminal est sobre et claire. La navigation dans l'arborescence est intuitive. Et il y a juste ce qu'il faut de raccourcis clavier pour faire l'essentiel.

Avec gdu -n, on peut aussi le lancer en mode non-interactif. Il y a une vingtaine d'options disponibles, par exemple -i et -I pour ignorer certains chemins ou motifs, -m pour fixer le nombre maximum de cœurs à utiliser, -o pour exporter toutes les données sur l'arbre dans un fichier au format JSON, -d pour analyser tous les disques montés, etc. Le README de sa page GitHub donne plus d'informations sur son fonctionnement (en particulier la gestion de la mémoire vive) et son fichier de configuration.

Le développement est actif. Je devrais peut-être signaler que la commande gdu -nd a un problème au niveau du formatage des colonnes… En tout cas, cette commande me plaît, je garde.

Digression sur ma source

Le blog dont je parlais est https://legeekheureux.fr/ . Les commentaires des articles suggèrent qu'il y aurait bien un auteur derrière. Mais je n'aime pas trop ces sites qui illustrent systématiquement chaque article avec des images générées par IA. Non seulement ces illustrations sont juste là pour faire beau (elles n'apportent rien au propos) mais elles jettent en plus le doute sur le texte lui-même : écrit par un humain, par un GPT, un mixte des deux ? C'est donc une pratique qui me semble à éviter pour un véritable auteur.

Quoi qu'il en soit, j'aime bien le motto du site :

“Nous autres, mordus d’informatique, préférons par-dessus tout passer notre temps à bidouiller nos ordinateurs, plutôt que les utiliser pour faire quelque chose de productif.”

  • # NCDU 2 le fait aussi

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

    D'après https://dev.yorhel.nl/ncdu la version 2 de NCDU possède le parallélisme également. Mais je ne l'ai pas testée, elle n'est pas empaquetée, et c'est en Zig, bref, ça me demande un gros effort :)

  • # VS ncdu

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

    Commandes

    /tmp/ncdu : ncdu 2.9.1 binaire statique téléchargé depuis https://dev.yorhel.nl/ncdu
    ncdu : ncdu 1.22 de Debian/unstable
    /tmp/gdu_linux_amd64 : gdu 5.31 téléchargé depuis https://github.com/dundee/gdu/releases/tag/v5.31.0

    Mon disque est un SSD Samsung 850 Pro

    Par défaut, gdu utilise 16 CPU, je l'ai donc testé à 8 également, pour le comparer à ncdu que je n'ai que testé à 8. Après tout, c'est le nombre de cœurs physiques de ma machine. Et je l'ai testé avec 1 seul CPU, pour le comparer à ncdu sur la non-parallélisation.

    Les tests sont lancés avec hyperfine.

    Test 1 : TMPFS de 4,2Go

    Mon /tmp possède un dépôt git de 1 Go et un cache de cargo en train de compiler. On teste donc la vitesse de calcul.

    Summary
  /tmp/ncdu -0 -o /dev/null -t8 '/tmp' ran
    1.91 ± 0.60 times faster than ncdu -0 -o /dev/null '/tmp'
    2.63 ± 0.85 times faster than /tmp/ncdu -0 -o /dev/null '/tmp'
    3.50 ± 1.10 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 '/tmp'
    4.25 ± 1.41 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null '/tmp'
    6.80 ± 2.14 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 '/tmp'

    Test 2 : /home/glandos

    Là, j'ai exclu les points de montage, j'ai du NFS, donc je n'ai gardé que ce qui se trouve sur mon SSD. J'ai fait également une première passe à blanc pour tout mettre dans le cache. Il y a quand même 144 Go.

    Summary
  /tmp/ncdu -0 -o /dev/null -t8 -x '/home/glandos' ran
    3.02 ± 0.05 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null -x '/home/glandos'
    3.19 ± 0.06 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 -x '/home/glandos'
    4.18 ± 0.07 times faster than /tmp/ncdu -0 -o /dev/null -x '/home/glandos'
    4.47 ± 0.08 times faster than ncdu -0 -o /dev/null -x '/home/glandos'
   11.43 ± 0.21 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 -x '/home/glandos'

    Test 2bis : on enlève les caches

    hyperfine est lancé avec --prepare "echo 3 > /proc/sys/vm/drop_caches" (et oui, j'ai lancé ça en root, c'est plus simple) qui va vider le cache entre chaque commande. Les commandes ne sont exécutées que 3 fois (au lieu de 10), parce que c'est vraiment trop lent sinon.

    Summary
  /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null -x '/home/glandos' ran
    1.12 ± 0.02 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 -x '/home/glandos'
    1.25 ± 0.05 times faster than /tmp/ncdu -0 -o /dev/null -t8 -x '/home/glandos'
    7.01 ± 0.13 times faster than /tmp/ncdu -0 -o /dev/null -x '/home/glandos'
    7.04 ± 0.15 times faster than ncdu -0 -o /dev/null -x '/home/glandos'
    7.87 ± 0.15 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 -x '/home/glandos'

    Test bonus

    ncdu 2.9.1 compilé en statique fait 768280 octets, soit 768 ko.
    gdu 5.31 compilé en statique fait 15413432 octets, soit 15 Mo.

    Ma conclusion

    Le parallélisme, c'est bien, mais j'ai l'impression que ncdu va rester mon choix. Ça va quand même plus vite sur tous les cas, sauf la version sans cache avec 16 flux d'exécution, et je n'ai même pas testé ncdu avec 16 flux…
    Et tout ça dans moins de 1 Mo statique, s'il vous plaît.

    Après, OK, gdu est plus joli.

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.