XFS.
O JFS é basicamente morto / não-mantido agora.
A maioria / todos os desenvolvedores do XFS agora trabalham no Redhat e o suporte ao kernel para o XFS está disponível imediatamente no RHEL 5.4.
Depois de decidir usar o LVM2 como gerenciador de volume em nossos servidores, também havia o desejo de um sistema de arquivos resizeable on-line. Depois de ler alguns artigos, decidi usar o JFS em favor do XFS.
Hoje, tive uma queda de energia no servidor do Office e descobri que um arquivo no volume do JFS estava completamente corrompido. Embora isso possa acontecer, o sistema me enganou e acreditou que tudo estava bem, não indicando nenhum problema no sistema de arquivos durante a inicialização após a falha de energia. Todos os sistemas de arquivos estavam limpos após a repetição do diário.
Isso me deixa com um gosto ruim. Eu não quero um sistema de arquivos que não se recupere bem após uma queda de energia, mas eu realmente não quero um sistema de arquivos que não me diga que pode haver um problema.
Então eu pensei em tentar e perguntar qual sistema de arquivos você prefere? Qual você favor e por quê? Estou procurando os seguintes recursos:
Eu também gostaria de saber se você usou o JFS e teve experiências ruins com ele - também, é claro, se houver histórias de sucesso usando o JFS. E finalmente: você preferiria o XFS sobre o JFS ou vice-versa (como mencionado para o uso diário, não para cargas de trabalho específicas)
Reproduzir um diário significa apenas que os metadados são colocados de volta em um estado limpo. Não faz garantias sobre os dados em si. Isso é verdade com qualquer sistema de arquivos com diário, pelo menos qualquer um que não faça outros truques como COW (Copy On Write). Portanto, há um potencial de corrupção de dados como este sempre que um servidor é encerrado sem limpeza, independentemente do sistema de arquivos selecionado. Seu sistema de arquivos fez o trabalho e conseguiu restaurar o sistema de arquivos para um estado limpo, minimizando a perda / corrupção de dados.
Assim, a lição aprendida com isso deve ser sempre ter seus servidores em um no-break que pode instruir o servidor para desligar corretamente quando a bateria está fraca. E sempre tenha bons backups.
Se você estiver realmente preocupado com a integridade dos dados, precisará migrar para um sistema de arquivos mais robusto, como o ZFS no OpenSolaris ou no BSD. É a única solução pronta para produção que eu conheço neste momento. O BTRFS no Linux será uma solução decente dentro de alguns anos, uma vez que esteja maduro e testado. Mas eu não recomendaria realmente usá-lo em um ambiente de produção neste momento. Mesmo esses sistemas de arquivos mais robustos não substituem os backups.
A mesma experiência que o Brad aqui.
O JFS foi muito bom desempenho e funcionalidade, mas eu perdi 3 partições de dados após um desligamento forçado.
Eu joguei o JFS no bin e usei o XFS no futuro (e aguarde o ZFS no Linux, assim como o BTRFS).
Será que alguém entre os "perdedores" acima mencionados tentou usar o fsck antes de desistir do JFS? O JFS @ Linux não possui código de recuperação de diário embutido no kernel e, portanto, requer o uso da ferramenta apropriada de espaço do usuário para isso.
O sistema de arquivos padrão Linux ext3 suporta o crescimento online e atende aos seus outros requisitos também. A menos que você tenha outras necessidades especiais, essa é realmente a resposta certa. Mesmo que o XFS tenha uma longa história e uma boa reputação, usá-lo ainda coloca você em um caso especial, o que é bom, mas vem com um custo inerente em maior complexidade - e por que "pagar" por algo que você não precisa? / p>
Eu usei o JFS em um ambiente profissional de grande escala e me queimei mal. Problemas de corrupção maciça que não apareceriam imediatamente, às vezes todos os arquivos acabariam em lost + found apenas de uma reinicialização limpa.
Alterado para o XFS e nunca mais olhou para trás. Utilizá-lo há 5 anos em centenas de sistemas de mutirabyte.