A resposta curta mudou à medida que a comunidade testou o ZimaOS
As primeiras respostas tratavam o ZimaOS como um sistema minimalista, ao estilo de um appliance, sem um gestor de pacotes tradicional. Recomendavam não presumir que apt install ou alterações permanentes ao sistema operativo base estariam disponíveis. O Docker e uma máquina virtual Debian ou Ubuntu foram propostos como limites de isolamento mais limpos.
Verificações práticas posteriores acrescentaram uma correção importante: um participante encontrou /usr/bin/mergerfs e mergerfs-fusermount já presentes num ZimaCube, mas não encontrou nenhum binário do SnapRAID. Outro participante identificou que o mergerfs incluído era uma versão mais antiga durante a resolução de problemas relacionados com uma condição de corrida no arranque. O resultado não foi “a instalação nativa é impossível”, mas sim “as alterações manuais no anfitrião não são suportadas e dependem da versão”.
Os binários manuais funcionaram, mas implicavam riscos durante as atualizações
Um utilizador compilou executáveis no WSL2, copiou-os para o ZimaOS e relatou uma configuração funcional com dois discos de dados e um disco de paridade. O responsável pela manutenção do mergerfs observou que as compilações estáticas podem simplificar a implementação manual, mas o comportamento dentro de contentores depende de o runtime ter privilégios de root suficientes para expor a montagem FUSE conforme necessário.
As respostas da comunidade alertaram repetidamente para o facto de copiar binários para um sistema de estilo imutável criar trabalho de manutenção. As atualizações OTA podem substituir ou entrar em conflito com alterações manuais, e as instruções de Linux geradas por IA continham erros durante as experiências do utilizador.
A comunidade criou uma camada systemd-sysext
Um colaborador publicou então um projeto comunitário systemd-sysext para o ZimaOS. O objetivo era adicionar o mergerfs e o SnapRAID como uma camada de extensão separada, em vez de modificar diretamente o sistema base apenas de leitura.
Um teste controlado num ZimaCube Pro confirmou que a camada era carregada, disponibilizava o mergerfs 2.42.0 e o SnapRAID 14.5, e conseguia montar um conjunto mergerfs descartável. O técnico criou um ficheiro através do caminho agrupado e verificou que este aparecia no ramo subjacente antes de desmontar corretamente.
Esse teste não incluiu um exercício completo de paridade e recuperação do SnapRAID. O técnico também desativou os temporizadores e serviços predefinidos antes de configurar qualquer elemento, para que não pudessem atuar acidentalmente sobre discos reais.
Foram encontradas e corrigidas duas condições de corrida no arranque
Após reiniciar, um utilizador descobriu que o conjunto por vezes falhava, embora um arranque manual posterior fosse bem-sucedido. O autor da extensão identificou duas condições de corrida distintas. Primeiro, a verificação original detetava o binário mergerfs antigo fornecido pelo sistema operativo base e iniciava o conjunto antes de o binário mais recente da extensão ser integrado. A verificação revista procurava o SnapRAID, que era fornecido apenas pela extensão.
Em segundo lugar, o mergerfs podia devolver sucesso antes de os discos físicos dos ramos estarem montados, produzindo um conjunto vazio que ocultava o armazenamento que chegava posteriormente. Um simples ciclo Restart=on-failure não conseguia detetar esse estado de sucesso, mas vazio. O projeto adicionou verificações explícitas que aguardam pela montagem de cada ramo e recusam criar o conjunto quando falta algum ramo.
O autor comunicou uma verificação após um arranque a frio no ZimaOS 1.6.1, depois destas alterações. Um utilizador com uma caixa TerraMaster de quatro discos também relatou que o conjunto acabou por aparecer depois de os discos demorarem quase um minuto a montar.
A segurança do SnapRAID continua a exigir revisão por parte do operador
A extensão incluía um limite de eliminação destinado a interromper a sincronização após um número inesperadamente elevado de eliminações. Um utilizador posterior questionou como ultrapassar esse limite depois de remover deliberadamente milhares de ficheiros. O tópico não encerrou essa questão operacional.
Qualquer pessoa que avalie o projeto deve rever os caminhos dos ramos, os caminhos de paridade, os temporizadores, os limites de eliminação e a localização dos dados das aplicações antes de ativar tarefas automatizadas. Uma verificação bem-sucedida dos binários ou uma montagem mergerfs não prova que a recuperação da paridade tenha sido testada para um conjunto de dados de produção.
Limites do suporte
Trata-se de uma integração avançada criada pela comunidade, não de uma funcionalidade de armazenamento do ZimaOS suportada pela IceWhale. O Docker, uma máquina virtual Linux completa, os binários estáticos e o sysext têm, cada um, diferentes privilégios e características de persistência. O resultado mais sólido do tópico é o método de extensão testado, mas este deve ainda ser avaliado em armazenamento descartável antes de introduzir quaisquer dados ativos.
FAQ
O mergerfs já está incluído no ZimaOS?
Um participante verificou a existência de um binário mergerfs no seu ZimaCube. Mais tarde, o tópico identificou essa cópia base como uma versão mais antiga, pelo que a sua presença não garante compatibilidade com uma configuração moderna.
A recuperação do SnapRAID foi totalmente testada?
Não. O teste controlado verificou a instalação e um conjunto mergerfs descartável, mas parou explicitamente antes de um teste completo de paridade e restauração do SnapRAID.
Porque não foi suficiente aguardar que um serviço falhasse?
Uma das condições de corrida podia produzir um conjunto vazio com um código de saída de sucesso. Como isso não era considerado uma falha, uma regra de reinício em caso de falha, por si só, podia não o detetar.
