Por que o JFS é tão obscuro?

Question

Quando comecei a usar o Slackware anos atrás, aprendi rapidamente a amar o JFS em relação ao ext3 ou ao reiserfs, já que era confiável e, se houvesse um desligamento impuro, a verificação do disco era muito rápida. Só recentemente descobri que o JFS é obscuro a ponto de ser quase completamente não mantido por ninguém.

Eu não tinha ideia de que estava em tal minoria. Por que isso aconteceu? É que a tecnologia do sistema de arquivos já avançou ao ponto de o JFS agora não ter nenhuma vantagem comparativa? É que ext3 foi mais interoperável com outros sistemas operacionais? Um determinado sistema de arquivos foi abençoado por um fornecedor em particular ou pelos desenvolvedores do kernel?

Não tanto uma questão técnica como histórica.

    

Answer 1

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

Eu sei que você está perguntando sobre 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é você se livrar da concorrência, as alternativas marginais terão um tempo excepcionalmente difícil de obter qualquer atenção.

Como o ext [234] não está indo embora, o JFS e sua turma estão em grande desvantagem desde o início.

(Este fenômeno é chamado a tirania do padrão.)

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

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

• A Red Hat e SuSE endossaram isso.

  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 deu suporte ao suporte XFS ao RHEL 5. O XFS estava disponível para RHEL 5 antes disso através do canal semi-oficial EPEL .

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

  Existem muitas outras distribuições Linux, e o RHEL e o SuSE não são as distribuições mais populares em todo o espaço do Linux, mas são as grande ferro distribuições de 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 que envolvem ferro, elas às vezes podem.

• O XFS é da SGI , uma empresa que está essencialmente fora agora. Antes de morrerem, eles formalmente cederam todos os direitos que tinham no XFS, então o pessoal do Linux sentiu-se à vontade incluindo-o no kernel.

  A IBM também deu 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 decidisse que seu suporte ao Linux não estaria mais alinhado com seus interesses, bem, isso poderia ficar feio.

  Claro, alguém provavelmente possui os direitos de PI da SGI agora e pode causar problemas, mas provavelmente não seria pior que o desastre da SCO . A IBM pode até pesar e ajudar a esmagar esse troll, já que seus interesses fazer incluem atualmente o suporte ao Linux.

  O ponto é que o XFS só se sente mais "livre" para muita gente. É menos provável que poste algum problema futuro de IP. Um dos problemas com nosso atual sistema de PI é que os direitos autorais estão atrelados ao tempo de vida da empresa, e as empresas geralmente não morrem. Bem, a SGI fez. Isso faz com que as pessoas se sintam melhor tratando a contribuição da SGFS do XFS como a contribuição de qualquer indivíduo.

• Em qualquer sistema que envolva efeitos de rede , onde você tem duas alternativas equivalentes - JFS e XFS, neste caso - você quase nunca receba uma divisão de mercado de 50/50.

  Aqui, os efeitos de rede são treinamento, compatibilidade, disponibilidade de recursos ... Esses efeitos levam o equilíbrio mais e mais para a opção que ganhou essa vitória inicial. Testemunhe o Windows vs. OS X, Linux vs. todos os outros- * ix, Ethernet vs. Token Ring ...

Answer 2

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

1. O JFS é uma porta de um sistema de arquivos criado para o AIX, depois portado para o OS / 2 e, em seguida, aberto de origem. Ele não tem nenhum dos desenvolvedores do AIX trabalhando nele, já que há um risco de contaminação de código, e o OS / 2 não foi desenvolvido por algum tempo.
2. Da minha leitura de código e seguindo o desenvolvimento do JFS, vi muitos problemas no código (um deles foi o fracasso de redimensionar o FS em máquinas big-endian, ou seja, aquelas feitas pela IBM) que foram corrigidas pelo projeto e não 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 daquela parte da árvore.
3. O código tem muitos problemas de legibilidade, que provavelmente contribuíram para a falta de suporte oficial por distribuições, já que é difícil depurar códigos difíceis de ler.
4. Assumo que um dos principais usos no início do JFS para Linux era migrar informações e compartilhar informações com sistemas AIX, mas no AIX5L não havia nenhuma opção (suportada) para usar o sistema de arquivos em um disco simples sem o proprietário LVM usado pelo AIX, que não estava disponível para Linux, e o JFS foi estendido sem que essas extensões fossem portadas para o Linux (veja o número 1).

Esclarecimento: Apesar de trabalhar na IBM no passado, nunca fui um membro da equipe de desenvolvimento do IBM AIX ou da equipe de desenvolvimento do JFS e essas razões assumidas são baseadas em minha dedução lógica e familiaridade com o histórico do sistema de arquivos e do Linux.