Hi ha una peça que fa anys que falta a les migracions des de VMware: el sistema de fitxers que deixa que diversos servidors muntin la mateixa LUN alhora i hi posin a sobre els discos de les màquines. Aquesta setmana s'han posat a circular dos candidats alhora; cap dels dos no va néixer aquesta setmana. Tots dos són lliures, tots dos empaqueten per a Debian i tots dos escriuen al seu propi README coses que no recordem haver llegit a la documentació pública de cap cabina que hàgim operat. La que decideix la conversa la signa MeshXFS i cap en una línia: «no release has been verified on a storage array».
El buit que notes des que vas marxar de VMware
VMFS no és glamurós, però fa una cosa molt concreta i molt difícil: diversos amfitrions munten alhora el mateix volum de bloc —una LUN d'iSCSI o de fibra— i els discos de les màquines virtuals hi viuen com a fitxers a sobre. Això és el que et permet tenir un magatzem central, moure màquines entre amfitrions sense copiar res i fer snapshots per fitxer. Quan surts de vSphere amb la cabina encara amortitzant-se, aquest és el tros que no té recanvi evident.
Proxmox VE sí que sap compartir una LUN: hi poses LVM a sobre i els volums lògics queden visibles per a tot el clúster. El que no tens és un sistema de fitxers, amb la qual cosa tampoc no tens fitxers: tens volums gruixuts, i durant anys tampoc no vas tenir snapshots. D'això en vam escriure fa unes setmanes, quan vam explicar migrar a Proxmox amb la teva cabina i descobrir que l'snapshot no viatja. Aquí hi ha el buit, i aquí és on han aterrat els dos projectes.
CetraFS: la coordinació la fa la mateixa cabina
CetraFS es presenta sense embuts com «un sistema de fitxers en clúster, de disc compartit, per a Linux; una alternativa moderna i oberta a VMFS». És un mòdul de nucli fora de l'arbre més tres eines d'espai d'usuari (mkfs.cetra, fsck.cetra, defrag.cetra), amb la 0.6 com a versió que empaqueta el repositori. L'interessant és com es posen d'acord els nodes: no hi ha xarxa. Cada reclamació en disputa —el pany de l'espai de noms, el d'obertura de fitxer, el registre del node, la propietat d'un grup de zones, un bit del mapa— és una sola operació atòmica SCSI COMPARE AND WRITE sobre un registre de 512 bytes. És la mateixa idea que l'ATS de VMFS, i el mateix projecte ho diu així.
La llista del que porta és seriosa: diari de refer per node, CRC32C verificat pel nucli en llegir, fitxers dispersos de fins a 16 TiB i una opció de muntatge nofilelock perquè una imatge pugui estar oberta en dos nodes durant el traspàs d'una migració en viu de Proxmox. No porta llistes de control d'accés POSIX. I el seu estat l'escriu el mateix projecte, en negreta, abans que res: «jove, pre-1.0. Molt revisat, sotmès a fuzzing i a proves de caiguda, però no curtit en producció com ho estan VMFS o ext4. Construït i provat sobre Linux 7.0.14 i 7.1.8+deb13 […]. Guarda còpies independents». Aquests dos nuclis són tota la llista; retén-ho per a la quarta comprovació de més avall.
MeshXFS: XFS amb clúster a sobre, i una declaració d'autoria
El segon projecte és MeshXFS (GPL-2.0), i agafa un altre camí: parteix de l'XFS del nucli i hi afegeix el que cal perquè diversos nodes muntin el mateix dispositiu en lectura i escriptura. Porta gestor de panys per xarxa o per disc —de nou COMPARE AND WRITE—, mòdul DKMS i un connector d'emmagatzematge per a Proxmox VE. I porta a la portada un paràgraf que no havíem llegit mai en un repositori d'aquest tipus: «MeshXFS va ser escrit enterament per IA, al llarg de moltes sessions de desenvolupament. Cap humà no va escriure, editar a mà ni revisar línia a línia el codi de clustering». Anomena l'agent principal —Claude Opus corrent de manera autònoma a Claude Code, que va escriure «bona part» del codi— i anomena també els models que va consultar en els problemes més durs, el disseny del protocol de panys, les curses de recuperació i la correcció del tancament: Claude Fable, GPT, Gemini i Astra, dels quals escriu que sense ells el projecte no s'hauria acabat. I acota la part humana: «dirigir la feina, fixar els requisits i executar les proves, no escriure la implementació». El propòsit que declara el projecte és literalment esbrinar si una IA podia escriure un controlador de dispositiu d'aquesta complexitat.
La nostra postura sobre això, ja que serà l'única cosa que es comenti: és la pregunta menys interessant que planteja aquell repositori. Un sistema de fitxers en clúster no es jutja per qui el va teclejar, sinó pel que ha sobreviscut i pel que el seu autor admet que no ha provat. I justament aquí MeshXFS documenta millor que la majoria de productes de pagament. Declara quinze configuracions publicades, anomenades amb un format de quatre camps (nodes/classe/mètode/connexió), i el llistó per publicar-ne una és explícit: cap defecte obert que pugui perdre dades ni tombar, penjar o parar un node. La cua de defectes és pública i es llegeix amb una eina del mateix repositori. Amb un matís que el mateix fitxer no resol: la seva taula diu que les quinze es van verificar a la 0.90.132, i unes seccions més avall els exemples d'aquesta mateixa eina diuen que diverses configuracions amb gestor de panys per xarxa es van verificar per última vegada a la 0.90.130. No concorda amb si mateix, i ho assenyalem precisament perquè és el document que estem elogiant.
Dos exemples que aquest llistó no és decoratiu. La versió 0.90.131 va ser retirada: comprovacions que van acabar després de publicar-la van trobar que podia deixar una entrada apuntant a un inode que un altre node acabava d'alliberar, i el projecte escriu que no s'hauria d'haver publicat abans que acabessin les comprovacions. I a la 0.90.132, la configuració de vuit nodes amb gestor de panys per xarxa sobre multipath va deixar de reclamar-se perquè, en sortir un node del clúster, els altres es van quedar esperant el pany d'un directori entre 66 i 77 segons. La de setze es va retirar amb ella, sense mesurar-la, fins que l'arranjament es verifiqui també allà. No va fallar cap operació ni es va perdre res; tot i així, el projecte ho anomena defecte i retira la reclamació. Aquest és el comportament que t'agradaria veure al portal de suport del teu fabricant.
La pregunta incòmoda: qui mata el node partit?
Aquí és on l'assumpte deixa de ser d'emmagatzematge i passa a ser d'arquitectura, i on els dos projectes contesten coses diferents a la mateixa pregunta. Un sistema de fitxers compartit sobreviu mentre només hi escrigui qui ha de fer-ho. Quan un node es queda aïllat però continua viu i amb la LUN al davant, algú l'ha d'apagar de debò. CetraFS ho diu sense maquillatge: per a producció multinode cal un gestor de clúster extern que faci tancament de hosts (STONITH), perquè el seu propi mecanisme és un temps d'espera de batec i un autotancament del node reclamat, però «no mata un host partit». I hi afegeix la comparació que ho explica tot: és «el mateix repartiment de responsabilitat que VMFS (l'arrendament sobre l'emmagatzematge) i vSphere HA (l'aïllament del host)».
Aquí hi ha la tesi de tot plegat: el que vas perdre en sortir de vSphere no va ser VMFS, va ser que les dues meitats vinguessin de fàbrica i compartissin rellotge. Si substitueixes només la d'emmagatzematge i dones per feta l'altra, tens mig clúster. MeshXFS contesta diferent: tanca el node mort amb reserves persistents SCSI sobre la mateixa LUN, llevat de DRBD i del mode de disc compartit per hipervisor, on el tancament el fa una autoritat externa —un IPMI, una regleta gestionada, el mateix hipervisor— o una confirmació de l'operador. Conseqüència pràctica i poc comentada: un dispositiu sense reserves persistents (virtio-blk, NVMe, un RAID per programari amb md) és rebutjat en muntar. Sense avís previ: simplement no munta.
A Proxmox l'altra meitat existeix: el gestor d'alta disponibilitat apaga per gos guardià el node que perd el quòrum. Però existeix si l'has configurat, i té el seu propi rellotge, que no és el del sistema de fitxers. Aquesta distància entre els dos rellotges és exactament el lloc on es perden dades, i en vam parlar en explicar per què l'alta disponibilitat de Proxmox no evita la caiguda, l'escurça.
Els 120 segons que gairebé ningú no ha mirat
El fragment més valuós dels dos repositoris és als requisits de CetraFS, a l'apartat de multipath, i descriu un parany que no és de programari nou: és de com funciona dm-multipath de sempre. Quan cauen tots els camins a la LUN, multipath no falla l'entrada/sortida: l'encua durant no_path_retry × polling_interval segons. El projecte posa l'exemple de l'entrada de fàbrica per a una HPE 3PAR: 90 segons. I hi afegeix la part que pocs lliguen: durant aquells 90 segons el node tampoc no pot enviar el seu batec, perquè el batec està encuat darrere dels mateixos camins morts.
Amb això muntat, la seqüència s'escriu sola. Si l'encuament de multipath dura més que la finestra d'obsolescència del sistema de fitxers, els altres nodes declaren mort el node callat i li reclamen els seus grups de zones mentre les seves escriptures continuen pendents. Després tornen els camins, la cua es drena i aquelles escriptures aterren sobre espai que ja pertany a un altre. CetraFS posa la finestra per defecte en 120 segons, precisament perquè hi càpiguen els 90 de fàbrica, i deixa ajustar-la entre 15 i 240 —sempre almenys el triple de l'interval de batec— amb stale_secs.
L'accionable és d'aquesta tarda i no depèn que instal·lis res: mira la teva configuració efectiva de multipath amb multipath -t, busca el no_path_retry i el polling_interval que apliquen a la teva cabina, multiplica'ls i guarda el número. Convé ser precisos amb què significa. La finestra de corrupció que descriu CetraFS necessita a més un sistema de fitxers que reclami l'espai d'un altre node; si avui fas servir LVM gruixut compartit, els volums tenen amo fix i aquesta finestra no la tens. El que sí que tens és el número: governa quanta estona es queda penjada la teva entrada/sortida abans de donar error, i per tant quant triga a reaccionar tot el que hi ha a sobre, començant pel gos guardià de l'alta disponibilitat de Proxmox i seguint pels temps d'espera de dins del convidat. Que estigui escrit al README d'un projecte pre-1.0 i no a la guia del teu fabricant és, francament, el més incòmode de tot plegat.
Totes dues, costat a costat
La frase que decideix la conversa
MeshXFS té un apartat titulat «el que això no cobreix», i obre amb el següent: «Tots els nodes amb emmagatzematge compartit són màquines virtuals. El banc de desenvolupament i els conjunts de plataformes són convidats KVM sobre un mateix amfitrió, i les LUN compartides són LUN iSCSI servides des d'aquell amfitrió. Cap versió publicada no s'ha verificat sobre una cabina d'emmagatzematge.» L'única excepció que admet és la configuració de dos nodes sobre DRBD, verificada a més en dues màquines físiques amb Proxmox VE 9 i els seus discos locals.
Ajunta això amb la resta que el mateix apartat reconeix i el quadre queda tancat: fibra i SAS no estan verificats, només els nuclis i les mides de clúster que la portada anomena un a un —«qualsevol altre nucli està sense provar, fins i tot a la mateixa distribució»—, la prova de remull dura trenta segons llevat que se'n demani una de més llarga, i la pèrdua de corrent a la cabina queda fora perquè la memòria cau d'escriptura ho ha de sobreviure. Hi ha a més una frase que hauria d'estar emmarcada a totes les sales de guàrdia: «la primera vegada que es van matar dos nodes alhora, sota càrrega, van aparèixer defectes que totes les proves d'una sola mort havien passat per alt».
CetraFS no fa aquesta declaració perquè no publica llista de configuracions verificades, però tampoc no afirma el contrari: la seva bateria automàtica corre sobre imatges en bucle, «mai sobre un dispositiu real», i les suites destructives o de maquinari real són opcionals i cal anomenar-los el dispositiu a mà. Cap dels dos, per tant, no et pot ensenyar avui una cabina verificada. Traduït a la decisió que tens al davant: si estàs sortint de VMware amb una cabina de fibra —el cas que més ens trobem— avui cap dels dos no et cobreix. L'un no ha verificat el teu transport; l'altre no ha verificat cap cabina, de cap mena. No és un retret als projectes, que ho diuen ells mateixos i a la seva portada.
L'opció oficial també porta l'etiqueta de vista prèvia
Abans que això soni que el programari lliure va al darrere: la resposta oficial de Proxmox a aquest mateix problema està en la mateixa situació. Proxmox VE 9.0 (5 d'agost del 2025) va introduir els snapshots com a cadenes de volums, que és justament el que et permet fer instantànies de màquines sobre emmagatzematge LVM gruixut compartit, el típic muntat sobre una LUN d'iSCSI o de fibra. Venia marcat com a vista prèvia tecnològica. Avui, 25 d'octubre del 2026, continua marcat igual: ho diu el full de ruta públic del projecte, on l'objectiu «treure els snapshots com a cadenes de volums (vista prèvia des de Proxmox VE 9.0) de la vista prèvia en LVM gruixut, Directori, NFS i CIFS, inclòs l'esborrat en calent de l'snapshot de més amunt» encara és a la llista del que falta per fer. Són 446 dies amb l'etiqueta posada.
I unes línies més avall, a la mateixa secció del full de ruta, apareix un altre pendent que descriu el terreny sencer: «millorar la integració i l'experiència de configuració de multipath per a desplegaments de fibra i iSCSI». És a dir, els tres camins que tens avui per posar una cabina sota un clúster Proxmox —els dos sistemes de fitxers nous i la via oficial— porten tots tres, per escrit, la paraula «encara». La diferència entre ells no és la maduresa: és a qui truques quan es trenca, i això sí que és una decisió de direcció i no de sistemes.
Què faríem nosaltres, i quan no tocaríem res
Nosaltres operem Proxmox VE amb Ceph en producció, en més d'una sala, i hem mogut empreses de VMware a Proxmox; també hem dit que no a alguna migració que no sortia a compte. Amb això al davant, el que faríem avui amb una cabina depèn d'una sola pregunta: si el ferro està amortitzat o no.
Si a la cabina li queden anys, es queda: LVM gruixut compartit per als discos de les màquines, i la vista prèvia de les cadenes de volums activada primer en un emmagatzematge que no sostingui res crític, amb el pla de còpies intacte. És menys elegant que un sistema de fitxers, però el camí l'ha recorregut molta gent. Si el ferro toca renovar-lo igualment, la conversa canvia de lloc: amb discos locals als nodes i emmagatzematge distribuït Ceph desapareix la LUN compartida, i amb ella el problema del sistema de fitxers, el del tancament i la finestra del multipath sencera. El que no desapareix és el cost: Ceph té les seves pròpies regles, comença en tres nodes i convé saber què fa i què no quan perds una peça, que és el que expliquem a un Ceph de tres nodes no es cura sol, aguanta.
Amb CetraFS i MeshXFS sí que recomanem una cosa: provar-los. En laboratori, amb dades que no importin, matant nodes a parells i reportant el que surti; tots dos porten cua de defectes i un procés de versions que converteixen un informe ben fet en una millora real. El que no faríem —i aquí no hi ha matís— és posar-los sota producció aquesta setmana perquè van funcionar al laboratori. Una prova de remull de trenta segons no diu res sobre el dimarts vinent.
Set comprovacions abans d'acostar un sistema de fitxers en clúster a una LUN de producció
- El teu transport és a la llista de verificats? No a la d'implementats: a la de verificats a la versió que instal·laràs. Fibra i SAS no hi són, a MeshXFS. CetraFS exigeix COMPARE AND WRITE atòmic, i es prova sense muntar res:
modprobe cetrafs caw_probe=<dispositiu>i mirar admesgquemax_caw_blockssigui almenys 1. - Qui mata el node partit, amb quin aparell i en quants segons? Si no pots anomenar l'aparell —un IPMI, una regleta gestionada, un hipervisor, una reserva SCSI— no tens tancament: tens un temps d'espera i bona sort.
- Multiplica
no_path_retryperpolling_interval(els veus ambmultipath -t) i compara-ho amb la finestra d'obsolescència del sistema de fitxers. Si el producte és més gran, tindràs una finestra de corrupció el dia que en muntis un. Si avui fas servir LVM gruixut, el que tens és entrada/sortida penjada més temps del que la teva alta disponibilitat triga a donar per mort el node, que tampoc no és innocu. - La teva versió exacta de nucli és a la llista? El nucli, no la distribució. «Qualsevol altre nucli està sense provar, fins i tot a la mateixa distribució», i en un mòdul fora de l'arbre això no és una fórmula legal, és literal.
- La memòria cau d'escriptura de la cabina sobreviu a un tall de corrent? MeshXFS ho exigeix i rebutja el muntatge en clúster si no l'hi declares. Si la teva resposta és «crec que sí», la resposta és no fins que algú ensenyi la fitxa de la bateria.
- Has matat dos nodes alhora, sota càrrega? És la prova que a MeshXFS va trobar defectes que totes les d'un sol node havien passat per alt. Matar-ne un i veure que aguanta és l'escalfament.
- Tens còpies independents del volum i les has restaurat? «Guarda còpies independents» és l'última línia de l'avís d'estat de CetraFS, i és la més barata de complir. Una còpia que no has restaurat és una hipòtesi, i aquí la hipòtesi és el pla B del pla B.
I amb tot això, què fas demà
Si estàs enmig d'una migració de VMware a Proxmox i la cabina és el nus que no desfàs, l'útil no és triar entre aquests dos noms: és decidir si el teu destí porta LUN compartida o no, perquè aquesta decisió arrossega el tancament, el multipath i els snapshots en bloc. És mitja tarda de conversa i es pot tenir abans de comprar res. Si vols que la tinguem amb tu —inclòs el càlcul dels no_path_retry de la teva cabina actual, que és gratis i sol sorprendre—, en parlem.
Fonts. L'existència i la posada en circulació dels dos projectes: article de Brandon Lee a Virtualization Howto, 24 d'octubre del 2026 (virtualizationhowto.com), única font secundària utilitzada i només per a això: l'existència dels projectes. Tota la resta està llegida directament dels repositoris, descarregats el 25 d'octubre del 2026. CetraFS (github.com/cetrafs/cetrafs): la definició com a «alternativa moderna i oberta a VMFS», l'avís d'estat «jove, pre-1.0 […] no curtit en producció com ho estan VMFS o ext4 […] guarda còpies independents», la coordinació per un únic SCSI COMPARE AND WRITE sobre un registre de 512 bytes amb la referència explícita a l'ATS de VMFS, els grups de zones per node, el diari de refer, el CRC32C, els 16 TiB per fitxer, l'absència de llistes de control d'accés POSIX, l'opció nofilelock, la versió 0.6 de l'empaquetatge, el repartiment de llicències (mòdul GPL-2.0 o posterior; eines AGPL-3.0 o posterior o comercial), el requisit de STONITH extern amb la frase «no mata un host partit» i la comparació amb el repartiment VMFS / vSphere HA, el paràgraf del multipath amb l'encuament de no_path_retry × polling_interval, els 90 segons de l'entrada de fàbrica d'HPE 3PAR, la finestra de 120 segons per defecte i el rang 15-240 de stale_secs, el «un paquet construït no és un paquet provat» i que el conjunt de dos nodes és l'única cosa que exercita els camins entre nodes. MeshXFS (github.com/sshoecraft/meshxfs): la llicència GPL-2.0 i la base en XFS, la declaració «escrit enterament per IA […] cap humà no va escriure, editar a mà ni revisar línia a línia el codi de clustering», la menció de Claude Opus a Claude Code i la delimitació de la part humana, les quinze configuracions publicades amb la seva nomenclatura de quatre camps, el llistó de publicació i la cua de defectes pública, la retirada de la 0.90.131, els 66 a 77 segons que van deixar sense reclamar les configuracions de 8 i 16 nodes amb gestor de panys per xarxa sobre multipath a la 0.90.132, el tancament per reserves persistents SCSI i el rebuig en muntar de dispositius sense elles (virtio-blk, NVMe, md), la no verificació de fibra i SAS, l'apartat «el que això no cobreix» amb «cap versió publicada no s'ha verificat sobre una cabina d'emmagatzematge», l'excepció dels dos nodes sobre DRBD en màquines físiques amb Proxmox VE 9, els trenta segons de la prova de remull, el «qualsevol altre nucli està sense provar, fins i tot a la mateixa distribució» i la troballa en matar dos nodes alhora. Proxmox VE: les citacions del full de ruta públic (pve.proxmox.com/wiki/Roadmap, secció Roadmap → Storage & Snapshots) sobre treure els snapshots com a cadenes de volums de la vista prèvia i sobre millorar la integració de multipath per a fibra i iSCSI, i la data de publicació de Proxmox VE 9.0 (5 d'agost del 2025) de la mateixa pàgina; els 446 dies són el nostre càlcul fins al 25 d'octubre del 2026. No hem provat cap dels dos sistemes de fitxers: aquest article llegeix la seva documentació, no mesura el seu comportament, i ho diu així expressament.
Microsoft 365
ES 
CAT 
EN