Parte 1: O Paradoxo do Disco Cheio e a Arquitetura do Sistema
A Anatomia de um Erro Frustrante
O erro no space left on device é o pesadelo de qualquer administrador de sistemas. Ele geralmente ocorre no pior momento possível: durante um deploy crítico, no meio de um backup de banco de dados ou quando um serviço vital de produção decide travar. No entanto, a verdadeira frustração começa quando você executa o comando padrão de verificação de disco:
df -h
E o resultado mostra, por exemplo, que você está usando apenas 60% da capacidade total. Como pode o sistema retornar no space left on device se existem centenas de gigabytes disponíveis? Para entender esse paradoxo, precisamos mergulhar na arquitetura do sistema de arquivos Linux.
Dados vs. Metadados
No Linux, o armazenamento não é apenas sobre o tamanho físico dos arquivos. O sistema de arquivos (como EXT4 ou XFS) separa a realidade em duas camadas:
- Blocos de Dados: Onde o conteúdo real dos seus arquivos (fotos, códigos, textos) é armazenado.
- Inodes (Índices): Uma estrutura de dados que armazena informações sobre o arquivo (quem é o dono, permissões, data de criação e, crucialmente, onde no disco os dados estão).
Quando o sistema operacional tenta gravar algo, ele pede um Inode e blocos de dados. Se qualquer um desses dois recursos faltar, você verá a mensagem no space left on device. A maioria das ferramentas de monitoramento básicas foca apenas nos blocos de dados, ignorando o “espaço administrativo” dos Inodes.
O Impacto nos Serviços Modernos
Em ambientes modernos de Docker e Kubernetes, o erro no space left on device tornou-se ainda mais frequente. Isso acontece porque containers geram uma quantidade massiva de arquivos temporários e logs de curta duração. Se a estratégia de limpeza de volumes não for rigorosa, o disco pode “encher” virtualmente em poucos dias, deixando o sysadmin confuso diante de um dashboard que diz que o disco está saudável.
Parte 2: O Vilão Invisível — Esgotamento de Inodes
Por que os Inodes acabam?
Como mencionamos, cada arquivo ocupa um Inode. Se você formatou seu disco com uma configuração padrão, o sistema criou um número fixo de Inodes baseado no tamanho total. Se você trabalha com milhões de arquivos minúsculos, você terá o erro no space left on device muito antes de usar todo o espaço em disco.
Imagine um servidor de cache que armazena fragmentos de HTML de 1KB. Se você tiver 10 milhões desses arquivos, você ocupará apenas 10GB de espaço em disco, mas se o seu limite de Inodes for de 8 milhões, o sistema travará.
Como Diagnosticar o Esgotamento
Para confirmar se este é o seu problema, esqueça o df -h. O comando que você precisa é:
df -iA saída mostrará colunas como IUsed e IFree. Se a coluna IUse% estiver em 100% (ou muito próximo disso), você encontrou a causa do seu no space left on device.
Estratégias de Limpeza Profunda
Quando o problema são os Inodes, apagar um arquivo gigante de 50GB não resolve nada. Você precisa apagar muitos arquivos, não importa o tamanho deles. Os culpados costumam se esconder em:
/var/lib/php/sessions/: Milhares de sessões de usuários antigos./var/spool/postfix/: E-mails na fila que nunca foram enviados./tmp/: Arquivos temporários de aplicações que não foram limpos.
Comando útil para localizar o diretório problemático: Este comando percorre o sistema e conta quantos arquivos existem em cada subdiretório do root, ajudando a isolar onde os Inodes estão sendo drenados e causando o no space left on device:
find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nPrevenção a Longo Prazo
Para evitar que o erro no space left on device retorne por falta de Inodes, considere:
- Mudar o sistema de arquivos: O XFS, por exemplo, gerencia Inodes de forma dinâmica, sendo mais resiliente a esse problema que o EXT4.
- Scripts de Purge: Configure Cron jobs para limpar pastas de cache e sessões a cada 24 horas.
Parte 3: Arquivos Fantasmas e Descritores de Arquivos Abertos
O Conceito de “Unlinked” no Linux
No sistema operacional Linux, a remoção de um arquivo é um processo de duas etapas. Quando você executa o comando rm arquivo.log, o sistema remove o “link” (o nome do arquivo) do diretório. No entanto, se um processo (como um servidor web Apache ou um banco de dados) ainda estiver com esse arquivo aberto, o espaço físico no disco não é liberado.
Este é o cenário mais comum para o erro no space left on device quando o df -h mostra espaço livre. O sistema entende que o espaço ainda pertence ao processo que o está escrevendo.
Como identificar arquivos deletados que ocupam espaço
Para encontrar esses arquivos “fantasmas” que estão causando o no space left on device, você não pode usar o comando ls. Você precisa consultar a tabela de arquivos abertos do kernel.
Execute o seguinte comando: sudo lsof +L1
Ou, de forma mais específica para encontrar deletados: sudo lsof | grep deleted
A saída mostrará o PID (Process ID), o nome do arquivo e o tamanho. Se você vir um arquivo de log com vários gigabytes marcado como (deleted), você encontrou o culpado.
Resolvendo sem reiniciar o servidor
Muitas vezes, administradores reiniciam o servidor inteiro para resolver o no space left on device. Embora funcione, isso causa downtime desnecessário. Existem formas mais elegantes:
- Reiniciar o serviço específico: Se o
lsofapontar que o serviçonginxestá segurando o arquivo, um simplessystemctl restart nginxliberará os blocos de dados instantaneamente. - Truncar o arquivo via FD: Se você não puder reiniciar o serviço, você pode esvaziar o arquivo através do descritor de arquivo no diretório
/proc.- Encontre o PID e o FD (File Descriptor) no comando
lsof. - Execute:
: > /proc/[PID]/fd/[FD]Isso forçará o arquivo a ter 0 bytes, liberando o espaço e resolvendo o erro de no space left on device imediatamente.
- Encontre o PID e o FD (File Descriptor) no comando
Parte 4: Blocos Reservados, Quotas e Fragmentação
A Reserva de Emergência do Root
Você sabia que, por padrão, o sistema de arquivos EXT4 reserva 5% do seu disco apenas para o usuário root? Em um disco rígido moderno de 4TB, isso significa que 200GB de espaço estão lá, visíveis, mas inacessíveis para o seu usuário comum ou sua aplicação.
Quando sua aplicação tenta gravar dados e atinge esse limite de 95%, o Linux dispara o erro no space left on device, mesmo que o administrador veja “vários gigabytes” sobrando no df. Essa reserva existe para garantir que, caso o disco lote, o usuário root ainda consiga logar e limpar o sistema sem que o SO trave completamente.
Ajustando a reserva com tune2fs
Em partições de dados (onde o sistema operacional não está instalado), manter 5% de reserva é um desperdício. Você pode reduzir isso para 1% para ganhar espaço e eliminar o erro no space left on device.
Use o comando: sudo tune2fs -m 1 /dev/sdb1 (Substitua pela sua partição)
Isso libera espaço imediato para as aplicações, corrigindo o problema de forma instantânea e segura.
Quotas de Usuário e Limites de Sistema
Se o erro no space left on device persistir apenas para um usuário específico enquanto outros conseguem gravar arquivos, você não está lidando com um disco cheio, mas com uma Quota de Disco.
- Verifique se há quotas ativas com o comando
quota -s [usuario]. - Verifique os limites de sistema (ulimit) com
ulimit -a. Se o limite de tamanho de arquivo (file size) estiver baixo, o sistema reportará erro de espaço ao tentar criar arquivos grandes.
Conclusão do Guia Completo
Ao longo deste artigo exploramos que o erro no space left on device é raramente sobre a falta de espaço físico real, mas sim sobre a exaustão de recursos lógicos: Inodes, File Descriptors ou Blocos Reservados.
Para manter um servidor saudável e evitar o no space left on device, siga o checklist:
- Monitore Inodes com
df -i. - Configure logs com
logrotatepara evitar acúmulo de arquivos pequenos. - Monitore processos que seguram arquivos deletados.
- Ajuste a porcentagem de blocos reservados em partições de armazenamento.
FAQ
Geralmente ocorre por esgotamento de Inodes (índices de arquivos) ou processos segurando arquivos deletados.
Utilize o comando df -i no terminal para ver a porcentagem de uso dos índices.
Reinicie o serviço que estava usando o arquivo ou mate o processo identificado pelo comando lsof
Em sistemas Btrfs, este erro pode ocorrer mesmo com muito espaço livre devido à falta de blocos de metadados. O Btrfs gere dados e metadados separadamente. Se os blocos de metadados estiverem cheios, o erro é disparado.
Solução: Execute um “balanceamento” do sistema de ficheiros para redistribuir os blocos: sudo btrfs balance start -dusage=55 /ponto/de/montagem
Sim. Se a sua aplicação utiliza o diretório /tmp ou /dev/shm (que muitas vezes são montados como tmpfs na RAM), o erro no space left on device pode referir-se à falta de memória volátil ou de espaço alocado para esse sistema de ficheiros virtual, e não ao disco rígido físico.
Como verificar: Use df -h /tmp para ver o limite específico da partição em memória.
O Docker é uma causa frequente de no space left on device devido a:
Volumes órfãos: Dados de containers antigos que não foram removidos.
Dangling Images: Camadas de imagens que já não são utilizadas.
Logs de containers: O ficheiro json-log de um container pode crescer indefinidamente se não houver um limite configurado no daemon.json.
Limpeza rápida: Execute docker system prune -a --volumes para libertar espaço imediatamente.
Em sistemas de ficheiros modernos (como EXT4 ou XFS), a fragmentação raramente causa no space left on device em termos de capacidade, mas em sistemas muito antigos ou em cartões SD/Flash quase cheios, a fragmentação extrema pode impedir a alocação de blocos contíguos para ficheiros muito grandes, embora o espaço total pareça suficiente.
du e o df mostram valores diferentes?Esta é a dúvida clássica. O du (disk usage) soma o tamanho dos ficheiros visíveis no diretório. O df (disk free) pergunta ao kernel quantos blocos de disco estão ocupados. Se o df mostrar muito mais ocupação que o du, é quase certo que existem processos a segurar ficheiros deletados (arquivos fantasmas), causando o erro de no space left on device.
Ficheiros esparsos são ficheiros que “fingem” ser maiores do que são (ex: um ficheiro de 1TB que ocupa apenas 1MB real). Se tentar copiar um ficheiro esparso para um disco que não suporta esta tecnologia ou tentar “preenchê-lo” totalmente, o erro no space left on device aparecerá quando os blocos físicos reais se esgotarem, independentemente do tamanho lógico reportado anteriormente.
Veja Mais:
Performance de Servidores Linux: Guia Completo 2026
Swap Alto com RAM Livre: Por Que Isso Acontece e como Resolver
Servidor Lento: Como Identificar o Gargalo
I/O de disco servidor Linux: Como Resolver Gargalos
CPU 100% no Linux: O Que Verificar Primeiro no Servidor
Como Usar vmstat para Achar Gargalo no Linux em Minutos
Load Average no Linux: Como Interpretar Corretamente
Como Achar Gargalo com Iostat: Guia Definitivo e Prático
Iowait Alto: Causas Reais e Soluções
Guia Completo de Monitoramento Linux com vmstat, iostat e sar
Tuning de sysctl para Produção: Guia Definitivo de Performance Linux
OOM Killer e MySQL: Como Evitar que o Linux Mate seu Banco de Dados
Como Ajustar limits.conf no Linux: Guia para Alta Performance
Memory Leak Linux: Como Detectar e Corrigir
Como identificar processo que consome CPU no Linux (Guia Completo)
Como Limitar CPU por Processo no Linux com cgroups (Guia Completo)
Upgrade de CPU ou Otimizar? Guia Completo
RAM Cheia no Linux: O Guia Definitivo para Resolver Travamentos em 2026
Buffers e Cache: Quando Deixam de Ajudar e Viram um Problema?
Out of Memory (OOM): Causas Reais, Diagnóstico e Como Resolver
Como evitar OOM Killer Linux em Produção: Guia Definitivo 2026
Gargalo no Linux: Como Identificar se o Problema é CPU ou RAM?
Disco Lento no Linux: Guia Completo para Identificar e Resolver
Latência de Disco no Linux Alta: Causas, Diagnóstico e Soluções