Ça a commencé par une question toute bête : “il reste quoi comme espace disque ?”. Ça s’est terminé une session entière plus tard avec 445 Go récupérés, un script de compression GPU découvert par accident, et une leçon d’humilité sur l’âge de mon GPU. Récap.

Le point de départ : 9,9 To et 97% plein

Le disque /mnt/user était à 97% d’occupation, 329 Go de libre sur 9,9 To. Mes 6 disques array étaient TOUS entre 82% et 97% individuellement — pas juste la moyenne, chacun. Il fallait creuser sérieusement, pas juste vider la corbeille.

Les doublons de torrents : attention aux hardlinks

qBittorrent avait 236 torrents en seed pour un total de 921,7 Go. Ma première intuition — “je vais juste supprimer les vieux torrents” — était fausse, et c’est là que ça devient intéressant.

Sous Radarr/Sonarr avec hardlinks activés, un fichier “seedé” dans /downloads/imported-movies/ et sa copie dans la vraie bibliothèque /downloads/Movies/ peuvent être le même espace disque physique, juste avec deux noms différents. Supprimer l’un des deux ne libère rien tant que l’autre existe.

J’ai vérifié via stat -c %h (le compteur de liens) sur chaque fichier :

stat -c 'Links=%h' fichier.mkv

• Links ≥ 2 → hardlinké, la bibliothèque a sa propre copie, supprimer le “seed” ne coûte rien mais ne rapporte rien non plus
• Links = 1 → soit un vrai doublon (copié au lieu d’être lié), soit un fichier jamais importé du tout

Résultat sur les 236 torrents : 155 hardlinkés (537,9 Go, rien à gagner), et 81 en Links=1 (383,9 Go). Sur ces 81, 26 étaient encore dans /incoming — pas des doublons, juste pas encore traités par Radarr, à ne surtout pas toucher. Les 55 restants étaient de vrais doublons complets.

La cause du problème : mon propre script de conversion GPU (voir plus bas) avait remplacé les fichiers de la bibliothèque par des versions HEVC compressées, cassant au passage le hardlink avec la copie qBittorrent — qui se retrouvait avec la version originale H.264, plus grosse, devenue orpheline.

Résultat : 278,6 Go récupérés, sans perdre un seul film.

La découverte du jour : mon propre script tournait en fond

En cherchant “pourquoi il y a un conteneur ffmpeg qui apparaît et disparaît dans docker ps”, j’ai retrouvé /mnt/cache/convert-movies.sh — un script que j’avais écrit et lancé il y a quelques jours, tournant en docker run --rm --gpus all un film à la fois, H.264 → HEVC via NVENC, avec une règle de sécurité stricte : jamais supprimer l’original tant que le fichier converti n’est pas vérifié (durée + taille + lisibilité).

Au moment du bilan : 56 films convertis, aucun échec, et déjà plus de 170 Go gagnés rien que sur ce chantier-là, en tâche de fond pendant que je m’occupais d’autre chose.

Le reste du ménage

Une fois les gros doublons de torrents réglés, j’ai enchaîné sur tout ce qui traînait :

Poste	Gain
Doublons torrents (hardlinks cassés)	278,6 Go
Backups Immich jamais purgés (dump quotidien depuis 2 semaines)	15 Go
Images Docker mortes (dangling)	7,8 Go
Appdata orphelins	1,7 Go
ISOs Linux/NAS EOL (CentOS 6/7, vieux TrueNAS, Fedora 30/35, OMV4, RHEL, Proxmox 7.0)	42,2 Go
Windows redondants/obsolètes	20 Go
macOS Big Sur en triple + VMware 6.5 (2016)	41 Go
Logiciels avec versions multiples (garder la plus récente)	~4,5 Go
Doublons ISO exacts (checksum vérifié)	34,65 Go

Total : environ 445 Go, sans compter les 170+ Go du script de conversion toujours actif.

Un piège que j’ai failli me prendre : en cherchant les dossiers appdata “orphelins” (sans conteneur du même nom), j’ai failli supprimer qbittorrentvpn-1 et influxdb — qui se sont avérés être les vrais dossiers actifs de qBittorrent et d’Influxdb-1.8, montés sous un nom différent du conteneur. Toujours vérifier les montages avant de supprimer un dossier appdata qui a l’air inutilisé.

La leçon CUDA : mon GPU a 10 ans de retard

Le vrai moment “oups” de la session. Immich (ma photothèque) tournait avec sa recherche IA (reconnaissance faciale, recherche sémantique) en CPU pur, faute de librairies CUDA dans l’image Docker — 730% CPU sur un process, de quoi faire grimper le load average à 40-60.

J’ai réparé ça en récupérant les libs CUDA/cuDNN manquantes directement depuis PyPI (l’image n’avait même pas pip, il a fallu télécharger et extraire les wheels à la main en Python pur), et tout s’est chargé correctement.

Sauf que quelques heures plus tard : la recherche Immich était cassée. Pas juste lente — cassée, erreur 500. En creusant les logs : CUDNN_STATUS_EXECUTION_FAILED / no kernel image is available for execution on the device.

Mon GPU — un Quadro M2000 — est une puce Maxwell de 2016. Les cuDNN 9.x modernes ne compilent tout simplement plus de kernels pour cette architecture. Résultat : les libs se chargeaient très bien, mais l’exécution réelle plantait à chaque fois, au lieu de retomber proprement sur le CPU comme avant.

La vraie leçon : parfois “faire marcher le GPU” n’est pas la bonne solution. J’ai supprimé les libs CUDA que j’avais ajoutées, forçant le retour au fallback CPU gracieux — plus lent, mais qui fonctionne. Certains matériels sont juste trop vieux pour l’écosystème CUDA actuel, et il faut savoir laisser tomber plutôt que s’acharner.

Ce que j’ai appris

1. Un hardlink cassé, c’est invisible tant qu’on ne vérifie pas stat -c %h — deux fichiers qui ont l’air d’être des doublons peuvent partager le même espace disque, ou pas du tout
2. Un script perso peut casser un hardlink sans prévenir — mon script de conversion remplaçait les fichiers en place, sans se soucier des liens existants ailleurs
3. Toujours vérifier les montages avant de supprimer un dossier appdata “orphelin” — le nom du dossier ne correspond pas toujours au nom du conteneur
4. Toutes les librairies CUDA du monde ne feront pas tourner un GPU Maxwell sur des kernels compilés pour Ampere/Ada — le hardware a une date de péremption, et forcer l’accélération GPU peut transformer un “lent mais fonctionnel” en “cassé”
5. Les checksums exacts (md5sum), c’est lent sur disques mécaniques sous charge — nom + taille identiques suffisent largement comme preuve pour des gros fichiers uniques (genre un ISO Windows Server avec sa clé de licence dans le nom)

Prochaine étape : configurer le partage Downloads pour rester sur un seul disque (ou en cache-only), histoire que les hardlinks arrêtent de casser à chaque fois qu’Unraid répartit les fichiers sur des disques différents.