Lo primero que debe quitarse de en medio es la comparación con ext[234] . Reemplazar cualquiera de ellos será como reemplazar NTFS en Windows. Posible, claro, pero requerirá una decisión desde arriba para cambiar.
Sé que está preguntando acerca de mantener las alternativas existentes, no la eliminación de otras alternativas, pero esa competencia privilegiada está absorbiendo la mayor parte del oxígeno en la sala. Hasta que te deshagas de la competencia, las alternativas marginales tendrán dificultades excepcionales para llamar la atención.
Desde ext[234] no van a desaparecer, JFS y los de su clase están en seria desventaja desde el principio.
(Este fenómeno se llama la Tiranía del Incumplimiento).
La segunda cosa es que tanto JFS como XFS se incorporaron a Linux aproximadamente al mismo tiempo y prácticamente resuelven los mismos problemas. Los geeks del kernel pueden discutir sobre puntos finos entre los dos, pero el hecho es que aquellos que se han topado con uno de ext[234] Las limitaciones de tenían dos soluciones aproximadamente equivalentes en XFS y JFS.
Entonces, ¿por qué ganó XFS? No estoy seguro, pero aquí hay algunas observaciones:
-
Red Hat y SuSE lo respaldaron.
RHEL 7 usa XFS como su sistema de archivos predeterminado, y era una opción de tiempo de instalación en RHEL 6. Después de que salió RHEL 6, Red Hat retroalimentó el soporte oficial de XFS para RHEL 5. XFS estaba disponible para RHEL 5 antes de eso a través de la publicación semioficial Canal EPEL.
SuSE incluyó XFS como una opción de tiempo de instalación mucho antes que Red Hat, desde SLES 8, lanzado en 2002. No es el valor predeterminado actual, pero ha sido compatible oficialmente todo el tiempo.
Hay muchas otras distribuciones de Linux, y RHEL y SuSE no son las distribuciones más populares en todo el espacio de Linux, pero lo son. las grandes distribuciones de hierro de elección. Están jugando donde más importan las ventajas de JFS y XFS. Estas empresas no siempre pueden mover al perro, pero en cuestiones que involucran hierros grandes, a veces pueden hacerlo.
-
XFS es de SGI, una empresa que prácticamente ya no existe. Antes de morir, entregaron formalmente todos los derechos que tenían en XFS para que la gente de Linux se sintiera cómoda al incluirlo en el kernel.
IBM también ha otorgado suficientes derechos a JFS para que los mantenedores del kernel de Linux se sientan cómodos, pero no podemos olvidar que son una empresa activa multimillonaria con miles de patentes. Si IBM alguna vez decidiera que su apoyo a Linux ya no está alineado con sus intereses, bueno, podría ponerse feo.
Seguro, alguien probablemente posee los derechos de propiedad intelectual de SGI ahora y podría armar un escándalo, pero probablemente no resultaría peor que la debacle de SCO. IBM podría incluso opinar y ayudar a aplastar a ese troll, ya que sus intereses sí actualmente incluyen compatibilidad con Linux.
El punto es que XFS simplemente se siente más "libre" para mucha gente. Es menos probable que plantee algún problema de IP en el futuro. Uno de los problemas de nuestro actual sistema de propiedad intelectual es que los derechos de autor están vinculados a la vida útil de la empresa y, por lo general, las empresas no mueren. Bueno, SGI lo hizo. Eso hace que la gente se sienta mejor al tratar la contribución de SGI de XFS como la contribución de cualquier individuo.
-
En cualquier sistema que involucre efectos de red donde tenga dos alternativas más o menos equivalentes, JFS y XFS en este caso, casi nunca obtiene una división de participación de mercado de 50/50.
Aquí, los efectos de la red son el entrenamiento, la compatibilidad, la disponibilidad de características... Estos efectos empujan el equilibrio más y más hacia la opción que obtuvo esa victoria temprana. Sea testigo de Windows frente a OS X, Linux frente a all-other-*ix, Ethernet frente a Token Ring...
Como alguien que ha trabajado extensamente con JFS en Linux y ha profundizado en el código fuente para solucionar problemas, puedo suponer varias razones:
- JFS es un puerto de un sistema de archivos creado para AIX, luego portado a OS/2 y luego abierto. Ninguno de los desarrolladores de AIX está trabajando en él, ya que existe el riesgo de contaminación del código, y OS/2 no se desarrolló durante bastante tiempo.
- Desde mi lectura de código y siguiendo el desarrollo de JFS, vi muchos problemas en el código (uno de ellos fue la falla al cambiar el tamaño del FS en máquinas big-endian, es decir, las fabricadas por IBM) que fueron corregidos por el proyecto y no se fusionaron con el kernel de la línea principal incluso meses después de la corrección, probablemente porque los desarrolladores de IBM no eran oficialmente los mantenedores de esa parte del árbol.
- El código tiene muchos problemas de legibilidad, que probablemente contribuyeron a la falta de soporte oficial de las distribuciones, ya que el código que es difícil de leer es difícil de depurar.
- Supongo que uno de los usos principales al comienzo de JFS para Linux era migrar información y compartir información con sistemas AIX, pero en AIX5L no había ninguna opción (compatible) para usar el sistema de archivos en un disco simple sin el propietario LVM utilizado por AIX, que no estaba disponible para Linux, y JFS se amplió sin que estas extensiones se transfirieran a Linux (consulte el número 1).
Aclaración:a pesar de haber trabajado en IBM en el pasado, nunca fui miembro del equipo de desarrollo de IBM AIX o del equipo de desarrollo de JFS y estas supuestas razones se basan en mi deducción lógica y familiaridad con la historia del sistema de archivos y Linux.