Lo Streaming è Rotto V: Hardlink e Permessi

Se salti questo post e vai direttamente al prossimo capitolo, il tuo server funzionerà perfettamente… per un po’. Ma poi noteresti l’inevitabile: hai scaricato un film da 50GB, ma lo spazio su disco consumato è aumentato di 100GB.

Di chi è la colpa? Dell’inefficienza del file system.

In questo post, risolveremo il più grande collo di bottiglia logico del nostro server: la duplicazione dei dati. Implementeremo la magia degli Hardlink e risolveremo definitivamente eventuali problemi di permessi Linux.

Hardlink

In una configurazione amatoriale, il flusso è questo:

1. qBittorrent scarica il film in /downloads.

2. Radarr (che “acquisirà” i nostri film) vede il file, lo copia in /movies, lo rinomina per farlo apparire bello e lo consegna a Jellyfin.

3. Risultato: Hai il file sporco (per il seeding dei torrent) e il file pulito (per la visione). Lo stesso film occupa il doppio dello spazio.

4. Il costo: Oltre a consumare metà del tuo SSD da 512GB, il processo di copia (I/O) stressa l’unità e utilizza CPU inutilmente.

Chi viene in nostro soccorso in questo scenario? Gli Hardlink!

Ma che diavolo sono? Pensa a un file sul disco non come a una “cosa”, ma a un indirizzo numerico che punta a una posizione fisica sull’SSD.

• Un file normale è un nome (movie.mkv) che punta all’indirizzo 12345.

• Un Hardlink è la creazione di un secondo nome (renamed_movie.mkv) che punta a quello stesso indirizzo.

Per il sistema operativo, appaiono come due file diversi in cartelle diverse. Ma occupano lo spazio fisico di uno solo. Figo, vero? Se ne cancelli uno, l’altro esiste ancora. Lo spazio viene liberato solo quando viene cancellato l’ultimo nome. In questo nuovo scenario, cosa abbiamo? Una “copia” istantanea (che richiede pochi millisecondi) e zero consumo di spazio aggiuntivo.

Ma come tutto nella vita, c’è un inghippo. Gli Hardlink non funzionano tra file system diversi.

In Docker, ogni volume mappato viene trattato come un file system isolato.

L’errore comune:

• Volume in qBittorrent: /home/user/downloads -> /downloads

• Volume in Radarr: /home/user/media -> /movies

• Per Radarr, /downloads e /movies sono dischi diversi. Non può creare un Hardlink. Copierà il file. Stesso problema.

Risolvere questo è semplice; mapperemo la cartella radice del nostro server in tutti i container.

• Host: /home/donkey/EmuleVision

• Container (Tutti): /data

All’interno del container, qBittorrent scarica in /data/downloads e Radarr lo sposta in /data/media. Poiché entrambi sono all’interno del volume /data, Linux permette l’Hardlink. La magia accade.

Permessi dei File

Linux è severo con la proprietà. Se qBittorrent (come Utente A) scarica un file, Radarr (come Utente B) non può modificarlo o rinominarlo. Ovviamente, non risolveremo questo problema eseguendo chmod 777 (permessi totali insicuri) su tutto.

Invece, utilizzeremo le variabili d’ambiente PUID (ID Utente) e PGID (ID Gruppo). Nel nostro file docker-compose.yml e .env, definiamo che tutti i container vengano eseguiti con l’identità del tuo utente principale (1000).

Niente di nuovo per chi già lavora con Linux, ma è sempre bene ricordarlo per non perdere tempo in seguito.

Nel prossimo capitolo, parleremo finalmente del nostro Docker Compose e di tutti gli strumenti di infrastruttura che utilizzeremo sul nostro server.