Nell’era del cloud, con storage e istanze replicate, non si sente parlare praticamente più di “clustered filesystem“. Eppure spesso sono ancora una componente essenziale di quella HA (High-Availability, che qui in italiano traduciamo spesso in “alta affidabilità” o “alta disponibilità”) di cui quelle tecnologie fanno vanto e fondamento. Quante volte avete sentito “i vostri dati sempre disponibili”, o “99.9999% di uptime“?

L’HA è proprio quello che lo rende possibile.

Proprio per questo, risulta essere importante l’arrivo di un filesystem (FS) usabile in un cluster, ad affiancare GFS2 o OCFS2 (ancora usati, ma piuttosto di nicchia). Soprattutto, se è il ben conosciuto (e tanto usato) XFS – quello usato di default da Red Hat e derivate (in genere).

Ma facciamo un passetto indietro per spiegare quanto l’aggiunta di “cluster” cambi la situazione.

Un FS è un componente che espone una serie di chiamate (previste e predefinite) al Kernel per la gestione di entità chiamate “file”, che hanno un loro contenuto e che sono identificate con un “path”.

Prendendo in considerazione solo i FS locali (XFS, ext4, btrfs, ZFS, ecc…), e non quelli di rete (NFS, glusterfs, ecc…), la caratteristica più comune e condivisa rimane l’essere accessibile esclusivamente da un sistema (Kernel) alla volta. Insomma, se quel FS è in uso sul mio PC (dal mio Kernel), allora nessun altro può usare quel FS, sicuramente non in scrittura, e spesso nemmeno in lettura.

Il limite serve per preservare l’integrità del FS stesso, talvolta le sue performance, e semplificare il codice.

Già, perché per permettere l’accesso simultaneo di più sistemi a quel FS, è necessario predisporre e integrare una serie di barriere (lock) e procedure per fornire alcune garanzie nell’uso. Per esempio, facendo un elenco non esaustivo:

• tutti i nodi vedano gli stessi dati (coerenza di cache e dato);
• le operazioni che possono entrare in conflitto siano coordinate e, quando necessario, serializzate, nell’ordine corretto;
• le operazioni indipendenti possano procedere in parallelo;
• la comparsa o (peggio) scomparsa di uno dei sistemi non abbia ripercussioni sull’integrità dei dati e – per quanto possibile – sugli altri nodi. Capirete quanto il compito sia molto più complesso, e quindi richieda del codice aggiuntivo. Ma allo stesso tempo quanto questo possa essere importante o potente: avere lo stesso disco (magari esposto via rete da un sistema, per esempio iSCSI) usabile da due o più computer allo stesso tempo, permette di avere bilanciamento dei carichi applicativi, o ridondanza degli stessi, o distribuzione istantanea dei file (che non devono essere sincronizzati/trasferiti tra i vari computer, perché direttamente accessibili da tutti nel disco condiviso).

Bene, se siete ancora con me, ora inizia la vera notizia.

Il solito Phoronix ci racconta che Steve Shoecraft ha iniziato un progetto per adattare XFS all’uso condiviso (cluster) e che il progetto stesso è nato un po’ per gioco, un po’ per sfida: vedere se una AI (e parliamo di Claude) poteva essere in grado di produrre un modulo del Kernel funzionante, completo e – per l’appunto – complesso, senza alcun intervento umano diretto sul codice.

Sulla pagina GitHub è possibile leggere che:

MeshXFS was written entirely by AI, across many development sessions. No human wrote, hand-edited, or line-by-line reviewed the clustering code.

• The coding agent: Claude Opus, running autonomously in Anthropic’s Claude Code, wrote a large share of the code.
• Consulted on the hardest problems: Claude Fable, GPT, Gemini and Astra, on lock-protocol design, recovery races and fencing correctness. Without them the project would never have been completed.
• The human’s part: directing the work, setting the requirements and running the testing, not writing the implementation.

MeshXFS è stato interamente scritto dall’AI, nel corso di varie sessioni di sviluppo. Nessun umano ha scritto, modificato a mano o rivisto linea per linea il codice di clustering.

• L’agente di programmazione: Claude Opus, in esecuzione autonoma in Claude Code di Anthropic, ha scritto larga parte del codice.
• Consultati sui problemi più difficili: Claude Fable, GPT, Gemini e Astra, sulla progettazione del protocollo di lock, race condition nel recupero e la correttezza del fencing. Senza di loro il progetto non sarebbe mai stato completato.
• Il ruolo dell’umano: dirigere il lavoro, definire i requisiti ed eseguire i test, senza scrivere l’implementazione.

Quindi l’intervento umano è stato essenzialmente direttivo. E se vi ricorda l’ultimo Torvalds, non avete torto, ma qui facciamo un passo (avanti, di lato?) in più: non c’è nemmeno revisione umana del codice, ma solo definizione degli obiettivi in termini di integrità e performance.

Il punto di partenza è stato il modulo XFS nel ramo di sviluppo del Kernel (6.19), scritto da umani, ma MeshXFS è molto più di una semplice estensione: il codice è cresciuto da circa 226k righe a 314k, ed è stato modificato in profondità. Perfino i test li ha scritti l’AI, a partire da criteri di successo e fallimento definiti dall’umano, che si è limitato a eseguirli.

The manifest lists every row with its budget. Every row must read PASS on the board (tools/criteria.py <configuration>. The board keeps each row’s last eleven runs, and a row with a genuine failure anywhere in that window does not read PASS: it has to pass lap after lap until the failure has left the window. A row that was skipped is not a pass either.

Every row also has a time budget, derived from twice what the same work takes on native XFS plus the measured cost of forming the cluster (tests/criteria/TIMEOUT_BUDGETS.md). Running over it is a failure, even when every byte is right.

Il manifest elenca ogni riga con il proprio budget. Ogni riga deve avere un PASS sulla bacheca (tools/criteria.py <configuration>). La bacheca tiene traccia per ogni riga degli ultimi 11 risultati, e una riga con un vero fallimento in un punto qualsiasi della finestra non ottiene un PASS: deve superare giro dopo giro finché il fallimento non esce dalla finestra. Anche una riga saltata non è un PASS.

Ogni riga ha anche un budget di tempo, calcolato sul doppio di quanto lo stesso lavoro impiega su XFS nativo più il costo misurato nella creazione del cluster (tests/criteria/TIMEOUT_BUDGETS.md). Andare oltre è un fallimento, anche quando ogni byte è corretto.

Considerando che i test sono più di 30, il codice prodotto non è solo valido ma anche prestazionalmente accettabile – se ci fidiamo dei test dell’AI.

Tra questi possiamo vedere anche alcuni casi d’uso reali, che non andiamo approfondendo ma che possiamo definire piuttosto interessanti:

• disco esportato in iSCSI, condiviso tra più host;
• disco sincronizzato tra due host tramite DRBD, in modalità active-active;
• gli stessi scenari come datastore per host Proxmox, ovvero per i dischi virtuali delle sue VM.

Pur considerando che i test sono girati quasi tutti su macchine virtuali, con storage iSCSI sullo stesso host, e che solo la coppia DRBD è stata provata anche su hardware fisico, si tratta di situazioni più che plausibili in contesti homelab o piccole (e medie) imprese, che al momento richiedono dei compromessi (rinunciare all’active-active, per esempio), o degli investimenti importanti (talvolta proibitivi) in hardware dedicato (una SAN con doppia testa, per intenderci).

Noi riteniamo il tutto davvero interessante. E forse anche inquietante: possiamo fidarci dell’AI?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.