Esta fonte mostra por que um disco de sistema ZimaOS cheio pode fazer com que a migração pareça bloqueada sem necessariamente destruir o RAID subjacente ou os dados do utilizador. O SSD de sistema de 228 GB do ZimaCube atingiu 0 B disponíveis depois de os dados de indexação/aplicação relacionados com o Resilio terem crescido na unidade do sistema operativo. O acesso através de SMB e do Finder continuava a funcionar, mas o painel ficou instável e a migração ficou inicialmente parada nos 5%.
A migração acabou por avançar — 45%, depois 49% — e finalmente foi concluída após mais de um dia. O autor original disse mais tarde que também impediu o Resilio de continuar a indexar/escrever no disco do sistema. A documentação atual do ZimaOS recomenda explicitamente manter o AppData fora da unidade do sistema.
O SSD do sistema estava completamente cheio
A migração dos dados das aplicações pareceu inicialmente bloqueada nos 5%
Um avanço lento não significava que a migração estivesse definitivamente bloqueada
Mais tarde, o utilizador viu a migração avançar para 45% e depois para 49% durante a noite. Meses depois, confirmou que acabou por ser concluída, provavelmente após mais de um dia.
As orientações atuais da IceWhale alertam explicitamente contra encher a unidade do sistema com AppData
As orientações atuais sobre os caminhos de armazenamento das aplicações indicam que bases de dados de aplicações, miniaturas, metadados e outros AppData podem encher a pequena unidade do sistema e fazer com que as atualizações, as aplicações e o próprio dispositivo funcionem de forma anormal.
Consulte as orientações atuais sobre o armazenamento de AppData.
Pare a aplicação que continua a encher o disco
Libertar alguns gigabytes não é útil se o Resilio, um modelo de LLM, a cache do Immich ou outro contentor os voltar imediatamente a ocupar. Identifique a aplicação que está a consumir o armazenamento do sistema e pare-a antes de tentar novamente a migração.
Crie margem de manobra antes de tentar novamente a migração
Um processo de migração precisa de espaço para bases de dados, estado temporário, registos e operações das aplicações. Elimine ou mova apenas dados que tenha identificado positivamente; não faça uma limpeza abrangente ao nível da raiz em diretórios de sistema desconhecidos.
Utilize a ferramenta atual de migração de dados quando o sistema estiver estável
O ZimaOS atual pode mover imagens Docker, dados de aplicações Docker e bases de dados de utilizadores geridas entre espaços de armazenamento através de Definições > Migração de dados.
Consulte o fluxo atual de Migração de dados.
Um número enorme de ficheiros pequenos pode ser mais lento do que o tamanho total sugere
Bases de dados de índices, miniaturas e diretórios de metadados podem exigir muito mais operações do sistema de ficheiros por gigabyte do que ficheiros multimédia grandes.
Não relocalize manualmente o AppData ativo durante a migração
Um participante posterior moveu manualmente uma pasta AppData de uma aplicação de LLM enquanto a migração já estava bloqueada. Isso pode fazer com que o caminho configurado da aplicação, o estado de migração do ZimaOS e a localização real no sistema de ficheiros deixem de coincidir.
A fonte também relatou um problema separado de nomes de ficheiros do Resilio
Meses depois, timothy disse que o Resilio tinha alterado o nome de ficheiros que continham caracteres não suportados, fazendo com que parecessem estar em falta no ZimaOS. Corrigiu explicitamente a suspeita inicial de que o ZimaOS tivesse perdido esses ficheiros.
Um painel avariado não significa que o conjunto de armazenamento se tenha perdido
A fonte ainda conseguia utilizar SMB e o Finder enquanto o painel terminava a sessão e a interface de migração se comportava de forma estranha. Esta distinção é importante: um disco de sistema cheio pode avariar os serviços do plano de controlo, enquanto a matriz de dados separada continua montada e legível.
Preserve essas provas antes de executar ações destrutivas no RAID ou de reinstalar o sistema.
Faça a triagem do disco do sistema antes de iniciar outra migração
Verifique que diretórios estão a consumir a unidade do sistema, identifique a aplicação responsável e pare o processo que está a escrever. Se a aplicação puder ser removida e recriada em segurança, remova os respetivos dados de cache/imagem descartáveis através dos controlos suportados, em vez de eliminar diretórios aleatórios.
Quando existir margem de manobra, reinicie apenas o serviço/aplicação afetado, conforme necessário, e confirme que o espaço livre permanece estável antes da migração.
A migração atual é uma operação controlada em ecrã inteiro
A documentação atual da IceWhale indica que as restantes operações ficam indisponíveis enquanto a Migração de dados está em execução. Planeie uma interrupção para as aplicações cujos dados estão a ser movidos, evite movimentos manuais simultâneos e deixe a migração atingir um estado claro de conclusão/erro antes de modificar as mesmas pastas.
A reinstalação é o último recurso, não a primeira resposta a 0 B disponíveis
Se os dados do utilizador e o armazenamento estiverem intactos, libertar espaço no sistema e concluir a migração do AppData pode recuperar o sistema sem reconstruir o NAS. Se for necessário reinstalar, faça primeiro uma cópia de segurança dos dados das aplicações, dos metadados do armazenamento e dos ficheiros críticos, seguindo as orientações atuais de recuperação/reinstalação.
Perguntas frequentes sobre um disco do sistema cheio
A migração da fonte acabou por ser concluída?
Sim. O autor original disse mais tarde que foi concluída após mais de um dia.
Uma barra de progresso de migração parada nos 5% prova que os dados se perderam?
Não. Na fonte, a migração avançou mais tarde, enquanto o SMB e o RAID continuavam acessíveis.
O que devem fazer primeiro os utilizadores atuais quando o ZimaOS-HD estiver cheio?
Pare a aplicação que continua a escrever, liberte espaço em segurança e utilize depois os controlos atuais de Migração de dados/AppData, em vez de eliminar ficheiros de sistema desconhecidos.
