“Built-in storage almost full” is a symptom, not a single ZimaOS bug. This source thread exposed at least three different causes: a Backup task whose USB destination disappeared and was effectively recreated under local /DATA, um registo JSON do Docker descontrolado que cresceu até 519 GB e um sistema diferente em que o aviso “o armazenamento integrado está quase cheio” é um sintoma, não um único erro do ZimaOS. Este tópico de origem revelou pelo menos três causas diferentes: uma tarefa de cópia de segurança cujo destino USB desapareceu e foi efetivamente recriado no armazenamento local em /DATA/.media consumiu 409 GB.
A resposta mais segura consiste em medir primeiro, identificar o serviço responsável, parar o processo que está a escrever e, em seguida, limpar apenas os dados confirmados. Não elimine /DATA/.docker, .media ou AppData recursivamente apenas por serem grandes.
/DATA apesar de o respetivo conjunto de dados de grande dimensão ainda ter vários terabytes disponíveis.Migrar os dados das aplicações não garante que todas as futuras gravações deixem de ocorrer em /DATA
Utilize verificações du só de leitura para encontrar a diretoria de maior dimensão
O utilizador de origem partilhou:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrIsto não modifica ficheiros. Repita o comando numa diretoria suspeita para restringir a pesquisa à subárvore de maior dimensão.
Um destino de cópia de segurança desligado foi a primeira causa confirmada
Cobblerkid descobriu que uma tarefa de cópia de segurança esperava uma unidade USB externa. Depois de a unidade ser desligada, a estrutura da cópia de segurança foi recriada em /DATA e a tarefa agendada continuou a escrever até o armazenamento local ficar cheio.
A Zima-Jerry concordou que isto parecia ser um problema e encaminhou-o internamente. Isto torna o caso mais do que uma teoria da comunidade.
Outro utilizador encontrou um registo JSON de contentor com 519 GB
Um segundo participante inspecionou o diretório de um contentor Docker e encontrou um *-json.log ficheiro com aproximadamente 519 GB, atribuído a um contentor do Home Assistant.
O utilizador removeu o contentor e recuperou espaço. Não generalize isso para “eliminar manualmente os registos do Docker”; primeiro identifique o contentor que está a gerar o volume anormal, inspecione os respetivos registos e corrija o erro repetido que os está a gerar.
Um terceiro sistema tinha 409 GB em /DATA/.media
Outro utilizador publicou uma discriminação do espaço ocupado, na qual os dados normais das aplicações ocupavam cerca de 225 GB, .docker apenas 3,5 GB, mas .media consumiu 409 GB. Isto demonstra por que razão um único comando de limpeza não pode resolver todos os casos de “disco cheio”.
A versão atual do ZimaOS expõe mais controlos de armazenamento e cache das aplicações
A documentação atual da IceWhale indica que Definições → Apps mostra a localização dos dados das aplicações e permite limpar a utilização/cache por aplicação. Manter o AppData na matriz de armazenamento principal reduz a pressão sobre a pequena unidade do sistema.
Utilize os controlos atuais de armazenamento das aplicações do ZimaOS antes de tentar limpar através da shell.
Uma ordem de recuperação mais segura
- parar a tarefa/aplicação que continua a gerar dados;
- medir
/DATAapenas de leitura; - identificar o ficheiro/pasta exato e o proprietário;
- fazer uma cópia de segurança do AppData/configuração importante;
- utilizar, sempre que possível, os controlos suportados das aplicações/cache;
- remover apenas dados descartáveis ou comprovadamente erróneos;
- confirmar que o espaço livre permanece estável após o reinício.
docker image prune não resolve todos os problemas de espaço do Docker
Na fonte, raller1028 mencionou docker image prune -a como forma de remover imagens não utilizadas pelos contentores. Isso pode recuperar camadas de imagens não utilizadas, mas não resolverá um registo JSON ativo de um contentor com 519 GB, um destino de Backup descontrolado ou dados de utilizador em .media.
Utilize a análise do tamanho para identificar primeiro a categoria. Um comando de limpeza direcionado para a categoria errada pode libertar quase nada, ao mesmo tempo que cria novos riscos.
Um registo JSON enorme significa que o ciclo de erros do contentor continua a ser relevante
Remover o contentor problemático libertou espaço para um utilizador, mas a melhor questão a longo prazo é perceber por que razão a aplicação escreveu centenas de gigabytes de registos. Inspecione os registos recentes à procura de erros repetidos, ciclos de reinício, dispositivos indisponíveis ou problemas de configuração antes de reinstalar a mesma carga de trabalho.
Se o contentor recriado começar imediatamente a gerar registos novamente, a situação de disco cheio irá regressar.
Trate .media como armazenamento gerido, não como uma cache descartável
Os 409 GB /DATA/.media o exemplo pode conter dados reais de montagem/ficheiros geridos, em vez de uma cache temporária. Antes de eliminar qualquer coisa aí, identifique que armazenamento/partilha/aplicação é o proprietário e confirme que os mesmos ficheiros existem noutro local.
FAQ sobre o armazenamento incorporado cheio
A fonte provou que a migração do AppData falhou?
Não. O autor original tinha migrado as categorias geridas; o preenchimento confirmado vinha de um destino de Backup desligado.
É seguro eliminar todo o diretório .docker?
Não. Pode conter o estado ativo dos contentores, registos, imagens e dependências de aplicações.
Qual é o melhor primeiro comando na fonte?
Uma du análise do tamanho de /DATA para identificar a subárvore grande real.
