O MeshXFS: sistema de arquivos clusterizado POSIX escrito por IA a partir do XFS. Entenda locks distribuídos, fencing e journal. Análise técnica completa, segura e detalhada do MeshXFS.
Você confiaria seus dados a um sistema de arquivos cujo código de clusterização não foi escrito, editado ou revisado linha por linha por nenhum ser humano?
Essa é a proposta do MeshXFS, um projeto open-source que pegou o maduro XFS do kernel Linux e o transformou em um sistema de arquivos clusterizados POSIX, com locking distribuído, fencing e recuperação de journal, usando o Claude Opus como agente autônomo de codificação.
Neste artigo, baseado em fontes primárias como o repositório oficial no GitHub e discussões técnicas, vou detalhar como o MeshXFS foi construído, o que já está validado, quais são suas limitações e o que isso significa para a confiabilidade de dados em ambientes de produção.
O que é o MeshXFS e por que ele importa
O XFS é um sistema de arquivos corporativo que acompanha o kernel Linux há anos. Tradicionalmente, um volume XFS só pode ser montado por uma única máquina por vez.
O MeshXFS quebra essa limitação: ele permite que vários nós montem o mesmo dispositivo de bloco compartilhado em modo leitura-escrita simultaneamente, algo comum em clusters de virtualização como o Proxmox VE.
O projeto é mantido por Stephen P. Shoecraft e está licenciado sob GPL-2.0. A versão mais recente no momento da redação é a 0.90.130, apelidada de "Stronger Recovery, Broader Platform Support". O MeshXFS se apresenta como um fork do código XFS do kernel Linux 6.19, com a árvore xfs/ tendo crescido de cerca de 226 mil para 314 mil linhas.
A grande questão – e o motivo de tanto debate – é que toda a camada de clusterização foi escrita por IA.
O Claude Opus, rodando como agente autônomo no Claude Code, foi o principal autor, consultando outros modelos (Claude Fable, GPT, Gemini e Astra) nos problemas mais difíceis: design do protocolo de lock, corridas de recuperação e correção do fencing.
O papel humano, segundo o próprio Shoecraft, foi definir a meta e o padrão: integridade de dados em primeiro lugar, nunca travar o host e ficar dentro do dobro do tempo do XFS nativo no mesmo armazenamento.
Como o MeshXFS funciona: locks, fencing e recuperação
Para que vários nós escrevam no mesmo disco sem se corromperem, o MeshXFS implementa uma pilha de coordenação distribuída. Segundo o anúncio e o repositório, os componentes principais são:
Dois gerenciadores de lock distribuído: um via rede entre os nós e outro que mantém o estado do lock no próprio disco compartilhado, usando o comando SCSI COMPARE AND WRITE, sem depender de uma rede de lock.
- Coerência de cache entre nós: para que um nó não leia dados desatualizados que outro acabou de escrever.
- Fencing com reservas persistentes SCSI: quando um nó para de responder ou perde todos os caminhos de armazenamento, os nós sobreviventes o isolam do disco para que ele não possa mais corromper dados.
- Recuperação de journal liderada por sobrevivente: cada nó tem sua própria fatia do journal. Um nó sobrevivente faz o fencing do nó morto, reproduz o journal dele e continua escrevendo.
- O repositório é específico sobre os limites operacionais: o MeshXFS dá 120 segundos para declarar um nó morto e 180 segundos para concluir o fencing. Esses números são importantes para dimensionar a tolerância a falhas em um cluster real.
O que já foi validado (e o que ainda não foi)
Apesar do ceticismo natural – e até de comentários no Hacker News de que o projeto "não parece pronto para produção" e que os benchmarks falham e são lentos –, o MeshXFS possui um processo de validação estruturado.
Cada release passa por uma suíte de aproximadamente 30 linhas de teste por configuração, em clusters multi-nó reais, cobrindo cenários do mundo real.
As configurações liberadas e validadas incluem:
O MeshXFS é empacotado como módulo DKMS para o Proxmox VE 9, RHEL 9, Ubuntu 24.04 e 26.04, Debian 12 e 13, e inclui um plugin de storage para o Proxmox VE.
Há também 123 registros de defeitos abertos, dos quais 69 afetam configurações já liberadas. Isso não é incomum em projetos jovens, mas é um alerta para quem pensa em adoção imediata.
Checklist para avaliar o MeshXFS antes de adotar
Copie e use esse Checklist
□ Confirme o número de nós: 2, 4, 8 ou 16 (32 nós está implementado, mas não liberado).
□ Revise os 123 defeitos abertos no repositório e verifique quantos afetam a sua configuração.
□ Teste o MeshXFS em um cluster de laboratório antes de qualquer dado de produção.
□ Use apenas as ferramentas do MeshXFS (mkfs.mxfs, chk_mxfs, resize_mxfs), nunca as ferramentas padrão do XFS.
□ Garanta que todos os nós executem a mesma versão do MeshXFS.
□ Planeje a janela de tolerância: 120 s para declarar nó morto + 180 s para fencing.
Questionário rápido (3 perguntas sobre o resumo)
1. Qual é a principal diferença entre o XFS tradicional e o MeshXFS em termos de montagem?
Resposta esperada: O XFS tradicional permite montagem apenas por um nó por vez; o MeshXFS permite que múltiplos nós montem o mesmo dispositivo de bloco compartilhado em leitura-escrita simultaneamente.
2. Quais tecnologias o MeshXFS usa para fencing e para o lock baseado em disco?
Resposta esperada: Fencing com reservas persistentes SCSI; lock em disco com SCSI COMPARE AND WRITE.
3. Quais são duas limitações importantes do MeshXFS na versão atual?
Resposta esperada: NVMe e NVMe-oF não são suportados (dependem de SCSI para fencing e locks); nenhuma release foi verificada em arrays de armazenamento; há 123 defeitos abertos, dos quais 69 afetam configurações liberadas.
Nenhum comentário:
Postar um comentário