XFS e JFS, descobri agora por que não são o padrão... ( resolvido pelo Edgy )

[greylica]

    Hoje, dia 7 de junho de 2007, aconteceu uma falha de energia elétrica grave por aqui, claro, que tentamos desligar tudo a tempo, e que haviam proteções suficientes para que não acontecesse o pior ( No-Break, Filtro de linha e aterramento adequado), mas, por mais que houvessem proteções, o desastre foi inevitável, bem como um raio que caiu em uma das empreas que atendo em meados de março. Pois bem, estava usando o diacho do JFS, acreditando que a porcaria era segura, ainda mais em se tratando de Linux.
    Muitos amigos já tinham avisado para não usar nem XFS nem JFS, por que corrompem com facilidade e os softwares apropriados não sabem recuperar nada direito. Dito e feito. Durante a queda de energia e a oscilação, a porcaria simplesmente acabou com dois HDDs meus e não existe comando que recupere a porcaria. a HDD está perfeita, mas os tais inodes e superblocks, junto com o tal de journal, não funcionam pra absolutamente nada além de propaganda inútil.  Eu me recupero, graças ao fato de ter backups comigo, aliás, um procedimento simples e útil. Claro que perdi algumas coisas que não estavam copiadas. ( Trabalhos recentes ), mas pelo menos não tenho motivos para sentar e chorar. MAssssss.
   XFS e JFS - vão para o inferno. daqui pra frente vou de boa e velha EXT2...

Fica o recado, por mais velocidade que essas coisas tenham (quase toda a banda disponível do HDD é conseguida, são um raio mesmo ), suas vantagens infelizmente não são páreo para segurança em se utilizar um sistema operacional. Pena, eu até gostava do formato de tag para os usuários, muito melhor que na EXT2 para controlar permissões, mas, em termos de segurança de dados, são horríveis. Deve ser por isso que os padrões do Linux são EXT2 e EXT3 respectivamente, alguém já deve ter se ferrado antes de mim...

[Glauco Hass]

Já li muito sobre os 2 sistemas, inclusive depoimentos de servidores com milhares de usuários de e-mail utilizando esses sistemas com sucesso, inclusive com journaling e tudo mais.
Mas teu depoimento é assustador. Já pensou perder alguns terabytes de informações importantes de terceiros por conta de uma simples queda de luz???

[greylica]

  O problema é que aqui nada resolveu o problema, com certeza eles devem ter ferramentas mais adequadas do que as que vem no Linux, providas ou pela Silicon ou pela IBM e é por isso que as coisas funcionam. Por que alguém é responsável. A situação aqui continua a mesma e ainda não desisti de tentar usar softwares para recuperação dos dados, só que os softwares reconhecem a partição, o conteúdo e alegam que não pode ser montada a partição por que os inodes e superblocos são inválidos, já verifiquei os discos sem destruição de dados paar ver se a superfície está OK ou se o acesso está normal. Tudo está normal, só que não monta, não dá replay vis JFS-Tools, não checa com fsck.jfs, não força montagem não faz absolutamente nada e nenhum software até agora foi capaz de mostrar os dados novamente. Andei lendo que esse suporte para replay de JFS e XFS no Linux ainda está em fase beta, ou seja, ele não dá replay nos dois sistemas e com isso somente através do comando
fsck.jfs -a  /dev/hda --replay_journal ou coisa assim
mas esse comando me retorna bad superblock e diz que as duas tabelas de inodes são inválidas, só, que são dois discos com o mesmo problema. Na hora que aconteceu o desastre, eu estava acessando dois arquivos, um de cada uma das partições. Tá me dando até enjoo só de pensar em ter de montar tudo de novo para trabalhar, mas, pode ser urucubaca maldita, mas sabe-se que isso sempre retorna para quem fez; em dobro...

[fabiovalinhos]

Não é só em Campinas não..aqui em Valinhos acontece umas loucuras na rede elétrica também.

Pior, acontecia comigo bem na hora de instalar ou atualizar algo.

Já liguei para CPFL reclamando ou querendo saber o que está acontecendo. Eles recomendaram, para mim,  desligar tudo pois estavam fazendo "testes" na rede.

7355

[greylica]

EEEEEEEEEENCONTREIIIIIIIIIII !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Não poderia deixar de dividir esta com vocês....
Claro que não gosto de falar mal de nenhum Linux, mas bugs são bugs e não tem como negar isso.
É o seguinte, temos um bug no JFS relacionado ao kernel do Linux, o que não acontece nos sistemas da IBM como AIX, onde ele é usado como padrão, no caso, o Ubuntu teve uma implementação que ainda estava em fase de beta teste, e não havia como garantir absolutamente nada, e isso estava bem escrito. Bem, houve um update do kernel para a resolução desse e de mais uns outros problemas, Só, que a parte do XFS progs e do JFS não foi afetada diretamente, mas sim indiretamente pela maneira que o kernel lida com o root do sistema. Em outras palavras, por mais que eu tentasse realmente mesmo através de sudos da vida fazer ou um fsck ou mesmo dar replay no JFS, o kernel estava entendendo que o fsck.jfs devia rodar como sistema e não como root !!! Bug neles. Como resolvi
Eu formatei esta máquina há mais ou menos um mês, mas, como sou precavido, eu havia comprado uma outra HDD para instalar o Kubuntu 7.04 e portanto eu ainda tinha o 6.10 á mão, e que, apesar de não instalar de cara o JFS durante a instalação, lida com o JFS normalmente, então baixei as ferramentas, e montei o sistema de arquivos JFS como read only. Eu procurei bastante na internet e vi diversos casos parecidos com o meu e o pessoal tinha as explicações de como resolver, rodar como read only pelo menos dá para fazer o backup.
     O que realmente me causou estranheza, foi o fato de particionadores como o Gparted e o Gnome partition, lerem o sistema de arquivo e interessante, até reconheceram o tamanho utilizado pela partição. Como eu fiz procedimentos não destrutivos para tentar recuperar meus dados, eles continuaram por lá. Agora, do início para o final, vou reformatar meu Linux, instalar todas as atualizações ( inclusive a que corrige isso ), sujar meu kernal com o driver proprietário da Nvidia, usar EXT2 e voltar a trabalhar...

    Mas, que foi um susto grande foi,
    Um bug da maneira como o sistema manuseia as permissões do kernel sobre o sistema de arquivos, quem diria... E eu quase chorando aqui, quem me salvou foi o edgy...
    Óbvio que vou relatar o problema e vou relatar também o problema de não fazer o journal logo quando o sistema inicia, vou relatar também a falta que faz a ferramenta rodar realmente como root e não como sistema...

Gente, desculpe meter o pau em XFS e JFS, mas precisamos de melhores implementações, e na verdade o que eu estou a fazer , é uma benéfice, por que eu realmente convivo com Linux todos os dias da minha vida, e , portanto, a convivência me dá o direito de apontar falhas e ver o que está errado, e isso também é uma colaboração... Outra coisa, não foi fácil encontrar a solução para o problema, ainda mais pelo fato de não ter digitado no google algo como " recuperar JFS " em inglês, eu tive de vasculhar mesmo blogs de pessoas que ficam espalhados pela Net e descobrir lendo...

[galactus]

Pois é, eu já tive dados corrompidos com o XFS, mas nunca testei o JFS. Hoje eu fico no EXT3 e no ReiserFS. Mas dá pena pela velocidade bem menor do EXT3 e ReiserFS frente a outros sistemas de arquivos. Infelizmente é isso ou perder os dados. Prefiro perder velocidade.

[leofergui]

Boa tarde... Hoje dia 3 de julho de 2009.
Percebo que este tópico tem mais de 2 anos e gostaria de deixar minha opinião sobre a fase atual do JFS.
Gostaria de informar que no início, o formato de arquivos JFS era muito instável, sofrendo assim perda de credibilidade por parte dos usuários Linux devido a tantos bugs encontrados.
Como exemplo, já enfrentamos situações em um servidor da IBM, P570 com AIX 5.2 e com sistema de arquivos JFS. Nesse servidor, de missão crítica, possuia o gerenciador de banco de dados DB2 8.1 e pelo simples fato de utilizarmos o comando de "db2move DB EXPORT -tn" nas tabelas no próprio disco, era uma luta infernal contra o tempo. Chegamos até utilizar método NFS para outro servidor, pois assim era mais rápido o procedimento.
Descobrimos, 3 anos depois, que era culpa do JFS. Assim que atualizamos para JFS2 tudo se resolveu lembrando de configurar os i-nodes.
Para quem me conheçe, sou suspeito em falar de IBM. O JFS tem muitas particularidades que os outros não possuem como o redimensionamento de partições sem a necessidade de desligar a máquina entre outras. Hoje em dia, eu utilizo ele como padrão do sistema de arquivos de meus clientes. Diria que, homologamos ele na nossa empresa. Assino em baixo... comparado aos outros existentes, ele realmente é muito mais rápido.
Conclusão... O JFS é muito bom para servidores.