Por que o JFS é tão obscuro?

Quando eu comecei a usar o Slackware anos atrás, aprendi rapidamente a amar o JFS sobre o ext3 ou reiserfs, pois era confiável e, se houvesse um desligamento impuro, a verificação do disco era muito rápida. Recentemente, descobri que o JFS é obscuro a ponto de ficar quase completamente sem manutenção por ninguém.

Eu não tinha ideia de que era uma minoria. Por que isso aconteceu? Desde então, a tecnologia do sistema de arquivos avançou a tal ponto que o JFS agora não possui vantagens comparativas? O ext3 foi mais interoperável com outros sistemas operacionais? Um outro sistema de arquivos foi abençoado por um fornecedor específico ou pelos desenvolvedores do kernel?

Não é uma questão técnica, mas histórica.

A primeira coisa que você precisa evitar é a comparação com o ext [234] . Substituir qualquer um deles será como substituir o NTFS no Windows. Possível, claro, mas exigirá uma decisão do topo para mudar.

Sei que você está perguntando sobre como manter as alternativas existentes, não a remoção de outras alternativas, mas essa concorrência privilegiada está sugando a maior parte do oxigênio na sala. Até que você se livre da concorrência, as alternativas marginais terão um tempo excepcionalmente difícil para conseguir atenção.

Como o ext [234] não está desaparecendo, o JFS e seus tipos estão em séria desvantagem desde o início.

(Esse fenômeno é chamado de tirania do padrão).

A segunda coisa é que o JFS e o XFS foram contribuídos para o Linux quase ao mesmo tempo e praticamente resolvem os mesmos problemas. Os nerds do kernel podem argumentar sobre pontos positivos entre os dois, mas o fato é que aqueles que se depararam com uma das limitações do ext [234] tinham duas soluções aproximadamente equivalentes no XFS e JFS.

Então, por que o XFS ganhou? Não tenho certeza, mas aqui estão algumas observações:

• A Red Hat e o SuSE endossaram.

  O RHEL 7 usa o XFS como seu sistema de arquivos padrão e era uma opção de tempo de instalação no RHEL 6. Depois que o RHEL 6 foi lançado, a Red Hat suportou o suporte oficial do XFS para o RHEL 5. O XFS estava disponível para o RHEL 5 antes, através do sistema semioficial Canal EPEL .

  O SuSE incluiu o XFS como uma opção de tempo de instalação muito mais cedo do que a Red Hat, voltando ao SLES 8 , lançado em 2002. Não é o padrão atual, mas foi oficialmente suportado o tempo todo.

  Existem muitas outras distribuições Linux, e RHEL e SuSE não são as distribuições mais populares em todo o espaço Linux, mas são as grandes distribuições de ferro de sua escolha. Eles estão jogando onde as vantagens do JFS e do XFS são mais importantes. Essas empresas nem sempre podem abanar o cachorro, mas, em questões envolvendo ferro grande, às vezes podem.

• O XFS é da SGI , uma empresa que se foi basicamente agora. Antes de morrerem, eles renunciaram formalmente a quaisquer direitos que possuíam no XFS, para que o pessoal do Linux se sentisse confortável em incluí-lo no kernel.

  A IBM também concedeu direitos suficientes ao JFS para tornar os mantenedores do kernel Linux confortáveis, mas não podemos esquecer que eles são uma empresa ativa e multibilionária com milhares de patentes. Se a IBM decidir que seu suporte ao Linux não está mais alinhado com seus interesses, bem, isso pode ficar feio.

  Certamente, alguém provavelmente possui os direitos de propriedade intelectual da SGI agora e pode fazer barulho, mas provavelmente não seria pior do que o fracasso da SCO . IBM pode até pesar e ajuda de squash, tais trolls um, já que seus interesses fazer atualmente incluem suporte Linux.

  O ponto é que o XFS parece mais "livre" para muita gente. É menos provável que haja algum problema futuro de IP. Um dos problemas com nosso sistema de IP atual é que os direitos autorais estão vinculados à vida útil da empresa, e as empresas geralmente não morrem. Bem, a SGI fez. Isso faz com que as pessoas se sintam melhor em tratar a contribuição da SGI do XFS como a contribuição de qualquer indivíduo.

• Em qualquer sistema que envolva efeitos de rede em que você tenha duas alternativas aproximadamente equivalentes - JFS e XFS nesse caso - quase nunca obtém uma divisão de participação de mercado de 50/50.

  Aqui, os efeitos de rede são treinamento, compatibilidade, disponibilidade de recursos ... Esses efeitos aumentam ainda mais a balança em direção à opção que conquistou essa vitória precoce. Testemunhe Windows x OS X, Linux x todos os outros- * ix, Ethernet x Token Ring ...

Como alguém que trabalhou extensivamente com o JFS no Linux e se aprofundou no código-fonte para corrigir problemas, posso assumir vários motivos:

1. JFS é uma porta de um sistema de arquivos criado para o AIX, depois portado para OS / 2 e, em seguida, aberto. Nenhum dos desenvolvedores do AIX está trabalhando nele, pois há um risco de contaminação do código e o OS / 2 não foi desenvolvido por algum tempo.
2. Na minha leitura de código e após o desenvolvimento do JFS, vi muitos problemas no código (um deles foi a falha de redimensionar o FS em máquinas big-endian, ou seja, as fabricadas pela IBM) que foram corrigidas pelo projeto e não foram foram mesclados no kernel da linha principal mesmo meses após a correção, provavelmente porque os desenvolvedores da IBM não eram oficialmente os mantenedores dessa parte da árvore.
3. O código tem muitos problemas de legibilidade, que provavelmente contribuíram para a falta de suporte oficial das distribuições, pois o código difícil de ler é difícil de depurar.
4. Suponho que um dos principais usos no início do JFS para Linux fosse migrar informações e compartilhar informações com sistemas AIX, mas no AIX5L não havia opção (suportada) para usar o sistema de arquivos em um disco simples sem o LVM proprietário usado pelo O AIX, que não estava disponível para Linux, e o JFS foi estendido sem que essas extensões fossem portadas para o Linux (consulte o número 1).

Esclarecimento: Apesar de trabalhar na IBM no passado, nunca fui membro da equipe de desenvolvimento IBM AIX ou da equipe de desenvolvimento JFS e esses motivos assumidos são baseados em minha dedução lógica e familiaridade com o histórico do sistema de arquivos e Linux.