Resolução de problemas de RAID do ZimaOS em hardware que não seja ZimaCube

Se o ZimaOS detetar as suas unidades, mas o ecrã de criação de RAID as atribuir às baías erradas, deixar ranhuras selecionáveis vazias ou apresentar apenas alguns discos, separe primeiro um problema atual de integridade do RAID do antigo problema de mapeamento de discos não ZimaCube documentado nesta discussão. A página 2 reflete em grande parte o comportamento do ZimaOS 1.2.x e das primeiras versões 1.3.x em hardware DIY.

A resolução de problemas de RAID no ZimaOS começa atualmente pela contagem de unidades, pelo estado dos discos, pela formatação individual, por um ponto de montagem vazio e por um reinício. Só depois dessas verificações deverá considerar soluções alternativas antigas de mapeamento de ranhuras — e apenas se conseguir reproduzir o mesmo defeito de mapeamento na sua versão atual.

Aspeto do antigo erro de mapeamento de discos

Vários utilizadores de hardware não ZimaCube relataram que as unidades fisicamente ligadas apareciam em posições virtuais inesperadas. A página de armazenamento podia mostrar discos nas baías 4, 5 e 6, enquanto a caixa de diálogo de RAID esperava discos em posições anteriores, deixando o botão Seguinte indisponível ou ocultando uma unidade da seleção.

Vista antiga do armazenamento do ZimaOS, mostrando discos não ZimaCube atribuídos a baías inesperadas — Uma versão antiga do ZimaOS mapeava os discos de hardware DIY para posições de baía inesperadas.

Gestor de Armazenamento antigo do ZimaOS, com discos apresentados nas baías 4, 5 e 6 — A interface de armazenamento podia reconhecer os discos, enquanto o modelo de seleção de RAID continuava a dificultar a sua utilização.

O reconhecimento e a elegibilidade para RAID eram duas camadas diferentes

Ecrã antigo de criação de RAID do ZimaOS em hardware LincStation, com ranhuras de disco indisponíveis — Um sistema DIY podia listar o armazenamento, mas ainda assim deixar incompleto o fluxo de trabalho de seleção de RAID.

Esta distinção continua a ser útil atualmente. Ver um disco em lsblk prova que o kernel vê um dispositivo de bloco. Vê-lo em Ficheiros ou no Gestor de Armazenamento prova que outra camada o reconhece. Poder selecioná-lo para RAID acrescenta ainda outra camada de elegibilidade e de interface.

Se uma camada falhar, registe onde o disco desaparece em vez de o apagar imediatamente. Verifique o estado do sistema de ficheiros, os metadados de RAID existentes, o estado de montagem e se a interface atual considera o disco disponível para uma nova matriz.

Painel antigo «Novo disco rígido» do ZimaOS, num caso de resolução de problemas de RAID num sistema não ZimaCube — A camada de armazenamento podia detetar uma unidade mesmo quando o fluxo de trabalho de RAID não a mapeava conforme esperado.

Ecrã antigo do RAID0 do ZimaOS, com apenas uma baía de disco selecionável em hardware DIY — Outra captura de ecrã mostra a mesma discrepância do lado da criação do RAID: o armazenamento detetado não foi convertido nas baías selecionáveis esperadas.

Execute as verificações atuais de RAID antes de editar a configuração do sistema

O guia oficial atual para resolução de problemas de RAID recomenda verificar pelo menos duas unidades, verificar o estado dos discos, confirmar que cada disco pode ser formatado com êxito, garantir que o ponto de montagem de RAID pretendido está vazio e reiniciar antes de tentar novamente a criação.

Lista de verificação atual para resolução de problemas de RAID no ZimaOS deve ser o seu primeiro recurso, mesmo em hardware DIY, porque evita pressupostos destrutivos.

SataStartNumber era uma solução alternativa da comunidade específica de uma versão

No tópico antigo, uma resposta da equipa da IceWhale reconheceu que a lógica inicial da interface do ZimaOS estava fortemente associada à disposição dos compartimentos do ZimaCube. Foi indicado aos utilizadores que inspecionassem a localização dos discos no controlador com lsblk -o hctl e, para determinados sistemas DIY, ajuste SataStartNumber em /etc/casaos/local-storage.conf.

Alguns utilizadores confirmaram que isto corrigia o mapeamento dos compartimentos virtuais; mais tarde, outros relataram que versões mais recentes do ZimaOS corrigiam a configuração sem manter a mesma solução alternativa. Isso torna a edição uma técnica histórica de compatibilidade, não um requisito universal atual.

Não aplique uma antiga SataStartNumber valor de outra placa-mãe. A topologia do controlador varia consoante o sistema, e o ZimaOS atual pode já não utilizar os mesmos pressupostos.

As capturas de ecrã mostram por que razão os limites entre versões são importantes

Gestor de armazenamento antigo do ZimaOS após a correção do mapeamento dos compartimentos dos discos — Mais tarde, um utilizador mostrou os discos a ocupar as posições de compartimento iniciais esperadas depois de o problema de mapeamento ter sido resolvido.

Ecrã de versão do ZimaOS, mostrando uma versão beta inicial 1.3.1 — Partes do tópico foram testadas em versões iniciais 1.3.x, muito mais antigas do que a interface atual da versão 1.7.x.

O ZimaOS 1.7.1 também inclui uma correção para a apresentação imprecisa do estado do RAID em determinados cenários. Isso não prova que todos os casos de mapeamento de compartimentos em sistemas DIY estejam resolvidos, mas é outra razão para reproduzir o problema numa versão atual antes de aplicar uma alteração de configuração de 2024.

Não transforme a solução alternativa da shell para cinco discos numa receita geral

Um participante posterior tinha cinco dispositivos NVMe de 8 TB. A interface apresentava apenas quatro para a criação do RAID, embora o quinto dispositivo estivesse visível noutro local, e o utilizador acabou por expandir manualmente o RAID5 com mdadm.

Vista antiga de armazenamento do ZimaOS, detetando cinco dispositivos NVMe, com um deles atribuído a um número de compartimento invulgar — O quinto NVMe estava visível para o sistema, mas tinha um mapeamento diferente dos quatro primeiros.

Lista de discos antiga do ZimaOS, mostrando cinco dispositivos membros de RAID Linux — A lista de discos e a interface de criação do RAID não apresentavam o mesmo conjunto utilizável.

Ecrã antigo de seleção de RAID5 do ZimaOS, proveniente do caso de resolução de problemas com cinco NVMe — O fluxo de trabalho do RAID5 fez parte das evidências utilizadas para comparar quais os discos que estavam visíveis e quais os que podiam ser selecionados.

Ecrã antigo de criação de RAID5 do ZimaOS, mostrando apenas quatro unidades NVMe selecionáveis — O quinto dispositivo não aparecia na etapa normal de seleção do RAID5.

Estado do RAID5 numa versão antiga do ZimaOS enquanto um quinto disco estava a ser incorporado — O utilizador acabou por expandir o conjunto a partir da shell, mas esse procedimento não é reproduzido aqui como recomendação geral.

Parar, voltar a montar ou expandir um conjunto com comandos de baixo nível pode causar perda de dados se a lista de dispositivos ou os pressupostos relativos aos metadados estiverem errados. Num sistema atual que reconhece os discos, mas não os consegue utilizar na interface RAID, faça uma cópia de segurança dos dados importantes e encaminhe o caso com a versão, lsblk saída, topologia do controlador, capturas de ecrã e estado atual do conjunto, em vez de copiar a antiga sequência de comandos da shell.