Pourquoi JFS est-il si obscur ?

La première chose dont vous devez vous débarrasser est la comparaison avec ext[234] . Remplacer l'un d'entre eux reviendra à remplacer NTFS dans Windows. Possible, certes, mais il faudra une décision d'en haut pour basculer.

Je sais que vous vous interrogez sur le maintien des alternatives existantes, et non sur la suppression d'autres alternatives, mais cette concurrence privilégiée aspire la majeure partie de l'oxygène dans la pièce. Jusqu'à ce que vous vous débarrassiez de la concurrence, les alternatives marginales auront beaucoup de mal à attirer l'attention.

Depuis le poste[234] ne disparaissent pas, JFS et ses semblables sont sérieusement désavantagés dès le départ.

(Ce phénomène s'appelle la tyrannie du défaut.)

La deuxième chose est que JFS et XFS ont été contribués à Linux à peu près au même moment, et ils résolvent à peu près les mêmes problèmes. Les geeks du noyau peuvent discuter de subtilités entre les deux, mais le fait est que ceux qui ont rencontré l'un des ext[234] Les limitations de avaient deux solutions à peu près équivalentes dans XFS et JFS.

Alors pourquoi XFS a-t-il gagné ? Je ne suis pas sûr, mais voici quelques observations :

• Red Hat et SuSE l'ont approuvé.

  RHEL 7 utilise XFS comme système de fichiers par défaut, et il s'agissait d'une option d'installation dans RHEL 6. Après la sortie de RHEL 6, Red Hat a rétroporté la prise en charge officielle de XFS vers RHEL 5. XFS était disponible pour RHEL 5 avant cela via le semi-officiel Canal EPEL.

  SuSE a inclus XFS comme option d'installation bien avant Red Hat, remontant à SLES 8, sorti en 2002. Ce n'est pas la valeur par défaut actuelle, mais il a été officiellement pris en charge pendant tout ce temps.

  Il existe de nombreuses autres distributions Linux, et RHEL et SuSE ne sont pas les distributions les plus populaires dans tout l'espace Linux, mais elles le sont les grandes distributions de fer de choix. Ils jouent là où les avantages de JFS et XFS comptent le plus. Ces entreprises ne peuvent pas toujours remuer le chien, mais dans les questions impliquant de gros fers, elles le peuvent parfois.

• XFS est de SGI, une entreprise qui a pratiquement disparu maintenant. Avant de mourir, ils ont officiellement cédé tous les droits qu'ils avaient sur XFS afin que les utilisateurs de Linux se sentent à l'aise de l'inclure dans le noyau.

  IBM a également cédé suffisamment de droits à JFS pour que les mainteneurs du noyau Linux soient à l'aise, mais nous ne pouvons pas oublier qu'il s'agit d'une entreprise active de plusieurs milliards de dollars avec des milliers de brevets. Si jamais IBM décidait que son support de Linux ne correspondait plus à ses intérêts, eh bien, cela pourrait devenir moche.

  Bien sûr, quelqu'un détient probablement les droits de propriété intellectuelle de SGI maintenant et pourrait faire des histoires, mais cela ne serait probablement pas pire que la débâcle de SCO. IBM pourrait même peser et aider à écraser un tel troll, puisque leurs intérêts font incluent actuellement la prise en charge de Linux.

  Le fait est que XFS semble plus "libre" pour beaucoup de gens. Il est moins susceptible de poser un futur problème IP. L'un des problèmes de notre système actuel de propriété intellectuelle est que le droit d'auteur est lié à la durée de vie de l'entreprise, et les entreprises ne meurent généralement pas. Eh bien, SGI l'a fait. Cela permet aux gens de se sentir mieux à l'idée de traiter la contribution de SGI à XFS comme celle de la contribution de n'importe quel individu.

• Dans tout système impliquant des effets de réseau où vous avez deux alternatives à peu près équivalentes - JFS et XFS dans ce cas - vous n'obtenez presque jamais une part de marché 50/50.

  Ici, les effets de réseau sont la formation, la compatibilité, la disponibilité des fonctionnalités... Ces effets poussent de plus en plus l'équilibre vers l'option qui a remporté cette première victoire. Témoin Windows contre OS X, Linux contre all-other-*ix, Ethernet contre Token Ring...

En tant que personne ayant beaucoup travaillé avec JFS sur Linux et exploré le code source pour résoudre les problèmes, je peux supposer plusieurs raisons :

1. JFS est un port d'un système de fichiers créé pour AIX, puis porté sur OS/2, puis open source. Aucun des développeurs d'AIX ne travaille dessus car il y a un risque de contamination du code et OS/2 n'a pas été développé depuis un certain temps.
2. D'après ma lecture de code et après le développement de JFS, j'ai vu de nombreux problèmes dans le code (l'un d'eux était l'échec du redimensionnement du FS sur les machines big-endian, c'est-à-dire ceux fabriqués par IBM) qui ont été corrigés par le projet et n'ont pas été fusionnés dans le noyau principal même des mois après le correctif, probablement parce que les développeurs IBM n'étaient pas officiellement les responsables de cette partie de l'arborescence.
3. Le code présente de nombreux problèmes de lisibilité, qui ont probablement contribué au manque de support officiel des distributions, car un code difficile à lire est difficile à déboguer.
4. Je suppose que l'une des principales utilisations au début de JFS pour Linux était de migrer des informations et de partager des informations avec les systèmes AIX, mais dans AIX5L, il n'y avait pas d'option (prise en charge) pour utiliser le système de fichiers sur un simple disque sans avec le propriétaire LVM utilisé par AIX, qui n'était pas disponible pour Linux, et JFS a été étendu sans que ces extensions soient portées sur Linux (voir numéro 1).

Clarification :Bien que j'aie travaillé chez IBM dans le passé, je n'ai jamais été membre de l'équipe de développement IBM AIX ou de l'équipe de développement JFS et ces raisons supposées sont basées sur ma déduction logique et ma connaissance de l'histoire du système de fichiers et de Linux.