Esta fonte acabou por produzir uma causa-raiz confirmada pela IceWhale. Depois de atualizar para o ZimaOS 1.5.3, o próprio array RAID NVMe foi montado e assemblado, mas zimaos-local-storage desmontou-o imediatamente porque a base de dados do RAID continha fs_type = 'BTRFS' em maiúsculas, em vez do valor em minúsculas esperado pelo gestor de armazenamento.
Dina, da IceWhale, forneceu uma atualização SQLite direcionada. O autor da publicação original executou-a e confirmou explicitamente que o RAID foi montado normalmente depois disso. O ZimaOS 1.5.4 listou então o problema de montagem automática do RAID com BTRFS em maiúsculas como um item oficialmente corrigido. Os utilizadores atuais devem, portanto, considerar o SQL como orientação histórica de recuperação para esse erro específico, e não como um comando geral de reparação de RAID.
O Array RAID Estava Saudável Antes de o Gestor de Armazenamento o Desmontar
O journal mostrava o kernel a detetar automaticamente o RAID e o systemd a montar /media/RAID-Storage-2, e depois zimaos-local-storage desmontava-o à força alguns segundos depois.
O registo da base de dados de origem também mostrava o RAID como estado ok. Isso tornava menos provável a existência de um membro avariado ou de um sistema de ficheiros Btrfs destruído.
O fstab Manual Funcionou Apenas como Solução Temporária
O utilizador montou manualmente o RAID e adicionou uma entrada /etc/fstab entrada, mas a gestão de armazenamento do ZimaOS não tratava isso como a configuração autoritativa. Após o reinício, o serviço local-storage continuava a impor a sua base de dados/estado interno.
É por isso que o armazenamento gerido pelo appliance deve normalmente ser reparado através da camada de armazenamento do ZimaOS, em vez de ser mantido como uma montagem manual paralela.
A Comunidade Identificou Corretamente zimaos-local-storage como a Camada Responsável
Antes de a IceWhale publicar a causa-raiz, gelbuilding apercebeu-se da sequência fundamental: a montagem é bem-sucedida e, de seguida, zimaos-local-storage desmonta-o. Aconselhou corretamente o envio dos registos à IceWhale, em vez de modificar repetidamente os metadados do RAID.
A sua especulação sobre uma validação mais rigorosa não foi o diagnóstico final; o diagnóstico oficial posterior foi muito mais específico.
A IceWhale Descobriu o Erro de Capitalização de fs_type
Dina escreveu que a base de dados fs_type o valor estava em maiúsculas, fazendo com que a montagem falhasse. A IceWhale forneceu:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"O utilizador respondeu mais tarde: “Isto resolveu efetivamente o problema.”
BTRFS em minúsculas btrfs.ZimaOS 1.5.4 Corrigiu Oficialmente o Mesmo Erro de Montagem Automática
As notas de lançamento da versão 1.5.4 listam explicitamente uma correção para a falha de montagem automática quando os registos da base de dados RAID estavam armazenados BTRFS em maiúsculas.
Consulte a correção oficial de montagem de RAID do ZimaOS 1.5.4.
Um utilizador posterior da versão 1.5.4 continuou a relatar que o RAID não estava montado
Outro participante afirmou que um problema de montagem continuava a ocorrer no seu sistema 1.5.4. A Dina pediu um diagnóstico recente do disco e uma descrição dos sintomas, em vez de presumir que ainda se tratava do erro de fs_type em maiúsculas.
Esse é o limite correto: sintomas semelhantes podem ter causas diferentes.
Não execute o SQL antigo num RAID atual sem evidências correspondentes
A versão atual do ZimaOS é a 1.7.1. Antes de tocar em local-storage.db, verifique se:
- o conjunto é efetivamente montado;
- o journal mostra o serviço de armazenamento local a desmontá-lo;
- a base de dados contém realmente o valor histórico em maiúsculas;
- tem uma cópia de segurança atual e um relatório de diagnóstico.
Se essas condições não corresponderem, editar a base de dados pode dificultar a recuperação de um problema de armazenamento diferente.
A correção oficial foi encontrada porque o utilizador forneceu os registos certos
A IceWhale pediu /ZimaOS-HD/.log/casaos/local-storage.log depois de a comunidade identificar a camada do gestor de armazenamento. Esse registo permitiu à equipa passar de uma teoria abrangente para o erro exato de capitalização.
Para uma falha de montagem atual, preserve o mesmo conjunto de evidências: estado da montagem do RAID, linhas do journal, estado do armazenamento do ZimaOS e diagnósticos do armazenamento local antes de modificar os metadados.
Faça uma cópia de segurança dos metadados internos antes de qualquer edição manual da base de dados
O SQL original era uma correção de uma linha fornecida pela IceWhale para um defeito conhecido da versão 1.5.3. Se voltar a ser necessária uma edição da base de dados orientada pela equipa de suporte, faça primeiro uma cópia de segurança da base de dados/estado e aplique apenas a condição exata que está a ser corrigida.
Atualizações SQL abrangentes dos registos RAID podem desligar a visão do gestor de armazenamento do conjunto real e transformar um erro de montagem recuperável num problema de recuperação de metadados.
Reinstalar não é a primeira resposta para um RAID saudável, mas não montado
Como o próprio conjunto foi montado e os dados estavam intactos, reinstalar ou recriar o RAID teria sido desnecessariamente destrutivo. Quando um conjunto saudável é rejeitado pelos metadados de gestão, repare a camada de gestão ou recorra ao suporte do fornecedor antes de alterar a geometria do conjunto.
FAQ sobre a montagem de RAID
O próprio RAID foi destruído na origem?
Não. O conjunto foi montado e montado no sistema antes de a gestão de armazenamento do ZimaOS o desmontar.
Qual foi a causa raiz confirmada?
A base de dados do RAID armazenava fs_type em maiúsculas BTRFS em vez de minúsculas btrfs.
A IceWhale corrigiu isto numa versão?
Sim. O ZimaOS 1.5.4 lista explicitamente como corrigido o erro de montagem automática de BTRFS em maiúsculas.
