Streaming Está Quebrado V: Hardlinks e Permissões
Se você pular este post e ir direto para o próximo capítulo, seu servidor funcionaria perfeitamente… por um tempo. Mas então você notaria o inevitável: Você baixou um filme de 50GB, mas o espaço em disco consumido aumentou em 100GB.
De quem é a culpa? É da ineficiência do sistema de arquivos.
Neste post, vamos resolver o maior gargalo lógico do nosso servidor: duplicação de dados. Vamos implementar a mágica dos Hardlinks e resolver quaisquer problemas potenciais de permissões do Linux de uma vez por todas.
Hardlinks
Em uma configuração amadora, o fluxo é assim:
qBittorrentbaixa o filme para/downloads.Radarr(que vai “adquirir” nossos filmes) vê o arquivo, copia para/movies, renomeia para ficar bonito e entrega para oJellyfin.Resultado: Você tem o arquivo sujo (para semear torrents) e o arquivo limpo (para assistir). O mesmo filme ocupa o dobro do espaço.
O Custo: Além de consumir metade do seu SSD de 512GB, o processo de cópia (I/O) estressa a unidade e usa CPU desnecessariamente.
Quem vem ao nosso resgate neste cenário? Hardlinks!
Mas o que diabos é isso? Pense em um arquivo no disco não como uma “coisa”, mas como um endereço numérico apontando para uma localização física no SSD.
Um arquivo normal é um nome (
filme.mkv) apontando para o endereço 12345.Um Hardlink é criar um segundo nome (
filme_renomeado.mkv) que aponta para esse mesmo endereço.
Para o sistema operacional, eles parecem dois arquivos diferentes em pastas diferentes. Mas eles ocupam o espaço físico de apenas um. Legal, né? Se você deletar um, o outro ainda existe. O espaço só é liberado quando o último nome é deletado. Neste novo cenário, o que temos? “Cópia” instantânea (levando alguns milissegundos) e consumo zero de espaço extra.
Mas como tudo na vida, há um porém. Hardlinks não funcionam entre sistemas de arquivos diferentes.
No Docker, cada volume mapeado é tratado como um sistema de arquivos isolado.
O Erro Comum:
Volume no
qBittorrent:/home/usuario/downloads->/downloadsVolume no
Radarr:/home/usuario/media->/moviesPara o
Radarr,/downloadse/moviessão discos diferentes. Ele não pode criar um Hardlink. Ele vai copiar o arquivo. Mesmo problema.
Resolver isso é simples; vamos mapear a pasta raiz do nosso servidor em todos os containers.
Host:
/home/donkey/EmuleVisionContainer (Todos):
/data
Dentro do container, qBittorrent baixa para /data/downloads e Radarr move para /data/media. Como ambos estão dentro do volume /data, o Linux permite o Hardlink. A mágica acontece.
Permissões de Arquivo
O Linux é rigoroso com propriedade. Se qBittorrent (como Usuário A) baixa um arquivo, Radarr (como Usuário B) não pode modificá-lo ou renomeá-lo. Claro, não vamos resolver isso rodando chmod 777 (permissão total insegura) em tudo.
Em vez disso, vamos usar as variáveis de ambiente PUID (ID do Usuário) e PGID (ID do Grupo). No nosso docker-compose.yml e arquivo .env, definimos que todos os containers rodam com a identidade do seu usuário principal (1000).
Nada novo para quem já trabalha com Linux, mas é sempre bom lembrar para não perder tempo depois.
No próximo capítulo, finalmente vamos falar sobre nosso Docker Compose e todas as ferramentas de infraestrutura que usaremos no nosso servidor.
