Le Streaming est Cassé V : Hardlinks et Permissions :: doismiu

Si vous sautez cet article et passez directement au chapitre suivant, votre serveur fonctionnera très bien… pendant un petit moment. Mais vous remarqueriez alors l’inévitable : vous avez téléchargé un film de 50 Go, mais votre espace disque consommé a bondi de 100 Go.

À qui la faute ? À l’inefficacité du système de fichiers.

Dans cet article, nous allons résoudre le plus grand goulot d’étranglement logique de notre serveur : la duplication des données. Nous allons mettre en œuvre la magie des Hardlinks et résoudre une fois pour toutes tout problème potentiel de permissions Linux.

Hardlinks

Dans une configuration amateur, le flux ressemble à ceci :

qBittorrent télécharge le film dans /downloads.
Radarr (qui va “acquérir” nos films) voit le fichier, le copie dans /movies, le renomme pour qu’il soit joli, et le livre à Jellyfin.
Résultat : Vous avez le fichier sale (pour le seeding des torrents) et le fichier propre (pour le visionnage). Le même film occupe le double de l’espace.
Le Coût : En plus de manger la moitié de votre SSD de 512 Go, le processus de copie (I/O) sollicite le disque et utilise du CPU inutilement.

Qui vient à notre rescousse dans ce scénario ? Les Hardlinks !

Mais qu’est-ce que c’est que ça ? Imaginez un fichier sur le disque non pas comme une “chose”, mais comme une adresse numérique pointant vers un emplacement physique sur le SSD.

Un fichier normal est un nom (movie.mkv) pointant vers l’adresse 12345.
Un Hardlink consiste à créer un deuxième nom (renamed_movie.mkv) qui pointe vers cette même adresse.

Pour le système d’exploitation, ils ressemblent à deux fichiers différents dans des dossiers différents. Mais ils occupent l’espace physique d’un seul. Cool, non ? Si vous en supprimez un, l’autre existe toujours. L’espace n’est libéré que lorsque le dernier nom est supprimé. Dans ce nouveau scénario, qu’avons-nous ? Une “copie” instantanée (prenant quelques millisecondes) et une consommation d’espace supplémentaire nulle.

Mais comme tout dans la vie, il y a un piège. Les Hardlinks ne fonctionnent pas entre différents systèmes de fichiers.

Dans Docker, chaque volume mappé est traité comme un système de fichiers isolé.

L’Erreur Courante :

Volume dans qBittorrent : /home/user/downloads -> /downloads
Volume dans Radarr : /home/user/media -> /movies
Pour Radarr, /downloads et /movies sont des disques différents. Il ne peut pas créer de Hardlink. Il copiera le fichier. Même problème.

Résoudre ceci est simple ; nous allons mapper le dossier racine de notre serveur dans tous les conteneurs.

Hôte : /home/donkey/EmuleVision
Conteneur (Tous) : /data

À l’intérieur du conteneur, qBittorrent télécharge dans /data/downloads et Radarr le déplace vers /data/media. Puisque les deux sont à l’intérieur du volume /data, Linux autorise le Hardlink. La magie opère.

Permissions des Fichiers

Linux est très strict sur la propriété. Si qBittorrent (en tant qu’Utilisateur A) télécharge un fichier, Radarr (en tant qu’Utilisateur B) ne peut pas le modifier ou le renommer. Bien sûr, nous n’allons pas résoudre cela en exécutant chmod 777 (permission totale non sécurisée) sur tout.

Au lieu de cela, nous utiliserons les variables d’environnement PUID (User ID) et PGID (Group ID). Dans notre fichier docker-compose.yml et .env, nous définissons que tous les conteneurs s’exécutent avec l’identité de votre utilisateur principal (1000).

Rien de nouveau pour ceux qui travaillent déjà avec Linux, mais c’est toujours bon de s’en souvenir pour ne pas perdre de temps plus tard.

Dans le prochain chapitre, nous parlerons enfin de notre Docker Compose et de tous les outils d’infrastructure que nous utiliserons sur notre serveur.