Streaming está Roto V: Hardlinks y Permisos

Si te saltas este post y vas directamente al siguiente capítulo, tu servidor funcionaría bien… por un tiempo. Pero luego notarías lo inevitable: Descargaste una película de 50GB, pero tu espacio en disco consumido aumentó en 100GB.

¿De quién es la culpa? Es la ineficiencia del sistema de archivos.

En este post, vamos a resolver el mayor cuello de botella lógico de nuestro servidor: la duplicación de datos. Implementaremos la magia de los Hardlinks y resolveremos cualquier problema potencial de permisos de Linux de una vez por todas.

Hardlinks

En una configuración amateur, el flujo se ve así:

1. qBittorrent descarga la película a /downloads.

2. Radarr (que “adquirirá” nuestras películas) ve el archivo, lo copia a /movies, lo renombra para que se vea bien y lo entrega a Jellyfin.

3. Resultado: Tienes el archivo sucio (para sembrar torrents) y el archivo limpio (para ver). La misma película ocupa el doble de espacio.

4. El Costo: Además de consumir la mitad de tu SSD de 512GB, el proceso de copia (I/O) estresa la unidad y usa CPU innecesariamente.

¿Quién viene a nuestro rescate en este escenario? ¡Hardlinks!

Pero, ¿qué diablos es eso? Piensa en un archivo en el disco no como una “cosa”, sino como una dirección numérica que apunta a una ubicación física en el SSD.

• Un archivo normal es un nombre (pelicula.mkv) que apunta a la dirección 12345.

• Un Hardlink es crear un segundo nombre (pelicula_renombrada.mkv) que apunta a esa misma dirección.

Para el sistema operativo, se ven como dos archivos diferentes en carpetas diferentes. Pero ocupan el espacio físico de solo uno. Genial, ¿verdad? Si eliminas uno, el otro sigue existiendo. El espacio solo se libera cuando se elimina el último nombre. En este nuevo escenario, ¿qué tenemos? “Copia” instantánea (tomando unos milisegundos) y consumo de espacio extra cero.

Pero como todo en la vida, hay una trampa. Los Hardlinks no funcionan entre diferentes sistemas de archivos.

En Docker, cada volumen mapeado se trata como un sistema de archivos aislado.

El Error Común:

• Volumen en qBittorrent: /home/usuario/downloads -> /downloads

• Volumen en Radarr: /home/usuario/media -> /movies

• Para Radarr, /downloads y /movies son discos diferentes. No puede crear un Hardlink. Copiará el archivo. El mismo problema.

Resolver esto es simple; mapearemos la carpeta raíz de nuestro servidor en todos los contenedores.

• Host: /home/donkey/EmuleVision

• Contenedor (Todos): /data

Dentro del contenedor, qBittorrent descarga a /data/downloads y Radarr lo mueve a /data/media. Dado que ambos están dentro del volumen /data, Linux permite el Hardlink. La magia sucede.

Permisos de Archivos

Linux es estricto con la propiedad. Si qBittorrent (como Usuario A) descarga un archivo, Radarr (como Usuario B) no puede modificarlo o renombrarlo. Por supuesto, no vamos a resolver esto ejecutando chmod 777 (permiso total inseguro) en todo.

En su lugar, usaremos las variables de entorno PUID (ID de Usuario) y PGID (ID de Grupo). En nuestro docker-compose.yml y archivo .env, definimos que todos los contenedores se ejecuten con la identidad de tu usuario principal (1000).

Nada nuevo para quienes ya trabajan con Linux, pero siempre es bueno recordarlo para no perder el tiempo después.

En el próximo capítulo, finalmente hablaremos de nuestro Docker Compose y todas las herramientas de infraestructura que usaremos en nuestro servidor.