O argumento mais forte neste tópico de pedidos de funcionalidades do ZimaOS em 2025 não foi simplesmente “adicionem outro sistema de ficheiros”. Os utilizadores queriam um modelo de armazenamento semelhante ao Unraid: manter discos formatados individualmente e de diferentes capacidades, apresentá-los como um único conjunto lógico e adicionar proteção por paridade sem converter toda a coleção numa matriz RAID distribuída convencional.
O Zima-Giorgio respondeu perguntando por que motivo a próxima opção JBOD do ZimaOS 1.4.2 não seria suficiente e pediu exemplos concretos de utilização no mundo real. As respostas tornam clara a distinção: o JBOD pode combinar capacidade, enquanto o MergerFS juntamente com o SnapRAID é apelativo porque separa o agrupamento da paridade agendada e permite aos utilizadores expandir uma coleção multimédia doméstica com discos diferentes ao longo de muitos anos.
Por que motivo os utilizadores de NAS domésticos pediram MergerFS e SnapRAID
Vários participantes descreveram armazenamentos que crescem gradualmente. Um utilizador tinha discos de 3 TB, 6 TB e 12 TB. Outro descreveu uma sequência em que um disco de 8 TB substitui um disco de 6 TB no NAS principal, o disco de 6 TB deslocado passa para um sistema de arquivo e um disco mais antigo desse sistema passa novamente para um servidor de laboratório doméstico.
O RAID tradicional pode ser pouco prático para esse padrão, porque a capacidade utilizável e as regras de expansão pressupõem frequentemente discos correspondentes ou cuidadosamente planeados. Os utilizadores queriam preservar o valor dos discos existentes em vez de reconstruir toda a matriz sempre que comprassem um disco maior.
O MergerFS e o SnapRAID resolvem problemas diferentes
O MergerFS é um sistema de ficheiros de união. Pode fazer com que vários sistemas de ficheiros independentes apareçam sob um único ponto de montagem lógico, enquanto os ficheiros continuam a residir nos discos individuais que compõem o conjunto.
O SnapRAID é software de paridade. Calcula informações de paridade a partir dos ficheiros existentes nos discos de dados e pode fornecer verificação da integridade. A sincronização da paridade é normalmente agendada, em vez de ser escrita continuamente como num RAID tradicional.
É essa separação que torna a combinação popular para coleções multimédia relativamente estáticas: o MergerFS fornece o espaço de nomes do conjunto, enquanto o SnapRAID fornece capacidade de recuperação em caso de falha de determinados discos.
Por que motivo o JBOD do ZimaOS não utiliza o mesmo modelo
A documentação atual do ZimaOS descreve o JBOD como a união de várias unidades num único volume contínuo. É uma opção de capacidade, não o mesmo modelo de paridade que os utilizadores estavam a solicitar.
Para conhecer as opções integradas atualmente disponíveis, compare as opções RAID e JBOD disponíveis no ZimaOS. O JBOD é útil quando o objetivo é simplesmente agrupar capacidade, mas não se transforma em SnapRAID apenas porque os discos que o compõem têm capacidades diferentes.
O autor do MergerFS participou na discussão
O Trapexit, programador do MergerFS, explicou que o CasaOS tinha utilizado historicamente o MergerFS para a funcionalidade de armazenamento “merge”. Já tinha discutido uma integração mais profunda com a IceWhale, mas afirmou que essas conversas não tinham evoluído para uma integração mais abrangente com o ZimaOS naquela altura.
Também descreveu um cenário de utilização adequado para o MergerFS: ficheiros que são escritos uma vez, lidos muitas vezes e alterados raramente, em que um conjunto lógico de sistemas de ficheiros independentes é mais importante do que um elevado desempenho de escrita aleatória.
Surgiu mais tarde no tópico um ecrã de junção do CasaOS
Esta captura de ecrã é uma evidência relativa ao CasaOS, não uma prova da existência atual de uma página de gestão do MergerFS suportada no ZimaOS.
Por que motivo os utilizadores consideram o SnapRAID diferente da paridade em tempo real
O tópico centrou-se repetidamente em arquivos multimédia cujos ficheiros não são alterados constantemente. A paridade agendada permite que os discos inativos entrem mais frequentemente em suspensão e evita exigir que todos os discos participem em todas as leituras. Os utilizadores também valorizavam as verificações de integridade do SnapRAID para detetar corrupção silenciosa.
A desvantagem é que as alterações feitas depois da última sincronização da paridade não ficam protegidas por esse instantâneo de paridade. Por isso, o SnapRAID não é um substituto direto para todas as cargas de trabalho RAID.
Aquilo com que a IceWhale se comprometeu efetivamente
As respostas oficiais foram cautelosas. O Zima-Giorgio começou por pedir aos utilizadores que explicassem por que motivo o MergerFS e o SnapRAID eram insubstituíveis em comparação com o JBOD. Em novembro de 2025, afirmou que a equipa tinha recebido o feedback e que iria reconsiderar o pedido.
Isso não equivale a um compromisso de produto, a uma data no roteiro ou a um anúncio de lançamento.
Estado atual
A documentação atual de armazenamento do ZimaOS continua centrada em discos individuais, JBOD, RAID e opções integradas relacionadas com ZFS. Atualmente, não existe uma página oficial de configuração do SnapRAID na interface de Armazenamento do ZimaOS.
Investigações posteriores da comunidade, em 2026, encontraram um binário do MergerFS em alguns sistemas ZimaOS e um projeto comunitário systemd-sysext que empacota o MergerFS e o SnapRAID. São desenvolvimentos relevantes, mas não equivalem a suporte oficial do SnapRAID com uma interface e um ciclo de vida suportados pela ZimaOS.
Escolha o modelo de armazenamento de acordo com a carga de trabalho
- Discos correspondentes e redundância contínua: utilize a opção RAID do ZimaOS que se adeque à tolerância a falhas de que necessita.
- Agregação simples de capacidade sem necessidade de paridade: o JBOD poderá ser suficiente.
- Multimédia de diferentes capacidades, maioritariamente estática, com paridade agendada: o MergerFS juntamente com o SnapRAID é o fluxo de trabalho solicitado pelos utilizadores neste tópico.
- Dados críticos sujeitos a alterações: mantenha cópias de segurança independentes, qualquer que seja a tecnologia da matriz.
A paridade não é uma cópia de segurança
O pedido diz respeito à sobrevivência a uma falha de disco, não à eliminação acidental, ao ransomware ou à destruição de todo o servidor. Um sistema MergerFS/SnapRAID continua a necessitar de um plano de cópias de segurança separado para os dados insubstituíveis.
Perguntas frequentes sobre o MergerFS e o SnapRAID
A IceWhale anunciou suporte oficial para o SnapRAID?
Não. A equipa pediu exemplos de utilização e afirmou mais tarde que iria reconsiderar o feedback.
O JBOD do ZimaOS é equivalente ao MergerFS juntamente com o SnapRAID?
Não. O JBOD agrega capacidade; o modelo solicitado combina um sistema de ficheiros de união com sincronização de paridade.
Existe trabalho comunitário relacionado com o MergerFS no ZimaOS?
Sim, mas os binários e módulos sysext da comunidade não devem ser descritos como uma funcionalidade oficial de gestão do SnapRAID.
