La prima cosa che devi togliere di mezzo è il confronto con ext[234] . Sostituire uno di essi sarà come sostituire NTFS in Windows. Possibile, certo, ma richiederà una decisione dall'alto per cambiare.
So che stai chiedendo di mantenere le alternative esistenti, non di rimuovere altre alternative, ma quella competizione privilegiata sta risucchiando la maggior parte dell'ossigeno nella stanza. Fino a quando non ti libererai della concorrenza, le alternative marginali avranno difficoltà a ottenere attenzione.
Da ext[234] non stanno andando via, JFS e simili sono in grave svantaggio fin dall'inizio.
(Questo fenomeno è chiamato la Tirannia del Predefinito.)
La seconda cosa è che sia JFS che XFS sono stati introdotti in Linux all'incirca nello stesso periodo e praticamente risolvono gli stessi problemi. I fanatici del kernel possono discutere sui punti delicati tra i due, ma il fatto è che coloro che si sono imbattuti in uno di ext[234] le limitazioni di avevano due soluzioni approssimativamente equivalenti in XFS e JFS.
Allora perché XFS ha vinto? Non ne sono sicuro, ma ecco alcune osservazioni:
-
Red Hat e SuSE lo hanno approvato.
RHEL 7 utilizza XFS come file system predefinito ed era un'opzione al momento dell'installazione in RHEL 6. Dopo l'uscita di RHEL 6, Red Hat ha eseguito il backport del supporto XFS ufficiale a RHEL 5. XFS era disponibile per RHEL 5 prima attraverso il semi-ufficiale Canale EPEL.
SuSE ha incluso XFS come opzione al momento dell'installazione molto prima di Red Hat, risalendo a SLES 8, rilasciato nel 2002. Non è l'impostazione predefinita attuale, ma è stata supportata ufficialmente per tutto il tempo.
Esistono molte altre distribuzioni Linux e RHEL e SuSE non sono le distribuzioni più popolari nell'intero spazio Linux, ma lo sono le grandi distribuzioni di ferro di scelta. Stanno giocando dove contano di più i vantaggi di JFS e XFS. Queste aziende non possono sempre scuotere il cane, ma in questioni che coinvolgono il ferro grosso, a volte possono farlo.
-
XFS è di SGI, una società che ora è sostanzialmente scomparsa. Prima di morire, hanno ceduto formalmente tutti i diritti che avevano su XFS in modo che la gente di Linux si sentisse a suo agio includendolo nel kernel.
IBM ha anche concesso diritti sufficienti a JFS per mettere a proprio agio i manutentori del kernel Linux, ma non possiamo dimenticare che sono un'azienda attiva, multimiliardaria con migliaia di brevetti. Se IBM decidesse mai che il proprio supporto a Linux non fosse più in linea con i suoi interessi, beh, le cose potrebbero diventare brutte.
Certo, qualcuno probabilmente possiede i diritti di proprietà intellettuale di SGI ora e potrebbe fare storie, ma probabilmente non sarebbe peggio della debacle di SCO. IBM potrebbe persino intervenire e aiutare a schiacciare un tale troll, dal momento che i loro interessi fanno attualmente include il supporto di Linux.
Il punto è che XFS sembra più "libero" per molte persone. È meno probabile che ponga qualche futuro problema IP. Uno dei problemi con il nostro attuale sistema IP è che il copyright è legato alla vita dell'azienda e le aziende di solito non muoiono. Bene, SGI l'ha fatto. Ciò fa sentire meglio le persone nel trattare il contributo di SGI di XFS come quello di qualsiasi contributo individuale.
-
In qualsiasi sistema che coinvolge effetti di rete in cui hai due alternative più o meno equivalenti, JFS e XFS in questo caso, non ottieni quasi mai una divisione della quota di mercato 50/50.
Qui, gli effetti di rete sono l'allenamento, la compatibilità, la disponibilità delle funzionalità... Questi effetti spingono sempre più l'equilibrio verso l'opzione che ha ottenuto quella vittoria iniziale. Assisti a Windows vs. OS X, Linux vs. all-other-*ix, Ethernet vs. Token Ring...
Come qualcuno che ha lavorato a lungo con JFS su Linux e ha approfondito il codice sorgente per risolvere i problemi, posso presumere diversi motivi:
- JFS è un porting di un filesystem creato per AIX, poi portato su OS/2 e quindi open source. Nessuno degli sviluppatori di AIX ci lavora perché c'è il rischio di contaminazione del codice, e OS/2 non è stato sviluppato per un bel po' di tempo.
- Dalla mia lettura del codice e seguendo lo sviluppo di JFS ho visto molti problemi nel codice (uno di questi era il fallimento del ridimensionamento di FS su macchine big-endian, cioè quelle realizzate da IBM) che sono stati risolti dal progetto e non sono stati fusi nel kernel principale nemmeno mesi dopo la correzione, probabilmente perché gli sviluppatori IBM non erano ufficialmente i manutentori di quella parte dell'albero.
- Il codice ha molti problemi di leggibilità, che probabilmente hanno contribuito alla mancanza di supporto ufficiale da parte delle distribuzioni, poiché il codice difficile da leggere è difficile da correggere.
- Presumo che uno degli usi principali all'inizio di JFS per Linux fosse la migrazione delle informazioni e la condivisione delle informazioni con i sistemi AIX, ma in AIX5L non esisteva alcuna opzione (supportata) per utilizzare il filesystem su un semplice disco senza il proprietario LVM utilizzato da AIX, che non era disponibile per Linux, e JFS è stato esteso senza che queste estensioni fossero portate su Linux (vedi numero 1).
Chiarimento:nonostante abbia lavorato in IBM in passato, non sono mai stato un membro del team di sviluppo IBM AIX o del team di sviluppo JFS e queste presunte ragioni si basano sulla mia deduzione logica e familiarità con la storia del filesystem e di Linux.