Notícia publicada por brain em maio 11, 2004 11:16 AM
| TrackBack
Neste longo artigo da Linux Gazette, o autor compara 5 sistemas de arquivo diferentes, todos em absoluta igualdade de condições, através de operações comuns: copiar grandes arquivos, localizar arquivos, criar diretórios, etc. A conclusão está no último parágrafo, e pode ser surpreendente para quem tem idéias pré-concebidas sobre o desempenho comparativo entre sistemas com e sem journaling..
Sempre achei o ext3 lento, mas pensei que era implicancia minha. Como o ReiserFs já me deixou na mão uma vez. A bola da vez, digo o file system da vez :) é o XFS.
Dirceu, concordo com você. O XFS já está rodando em meu servidor de email a mais de 1 ano sem problemas e já passou por uns 5 crashs de energia.
Para o usuário domestico, o que é recomendado? Tem como converter um ext3 para reiserFS?
o rh9 suporta nativamente o raiserfs ???
em materia de segunrança reiser é melhor porem ele pega 30 mb do seu hp , ext3 tambem é bom falar a verdade eu não vejo muita diferença entre ext3 e reiser ou seja não copença troca um pelo outro não agora o xfs anda promentendo , assim sem falar o tão prometido reiser 4 que dis melhorar a velocidade de leitura.
agora o que deveria nem ser mencionado de tão ruim que é o ext2
O redhat nao tem suporte a reiserfs nativamente... eu nao entendo isso.
Agora esse REISER4 que não sai hein... putz, ja estamos quase na versao 2.6.7 do kernel e ele ta em experimental ainda... bom tem um lado positivo ne, espero que eles so liberem mesmo quando estiver realmente estavél, pq arquivo é uma coisa muito seria para colocar em um sistema de arquivos imaturo.
Mas assim que sair o reiser4 eu aplico o patch no kernel na hora. Ele é surpreendentemente mais rapido alem de fazer as coisas em formas de transações (ou a operaçao é totalmente realizada ou não é realiada), o que no meu entendimento significa reduzir a quase zero os arquivos corrompidos no HD.
Aproveitando a deixa do assunto...
funciona exportar o /HOME dos usuarios em um unico servidor NFS para mais ou menos 100 maquinas?
Ou o NFS nao serve para isso? Ja que o NFS é UDP ele nao tem verificaçao de erro? Ou o erro é verificado no protocolo de aplicaçao (o proprio NFS)?
Alguem aqui usa algum desses novos sistemas de arquivos(AFS, CODA, INTERMEZO)?
Aqui onde eu estudo há um servidor rodando NFS, para em torno de 35 máquinas. O /home de todos usuários fica neste servidor, e ninguém sente diferença nisso.
Apesar do NFS rodar em UDP, não significa que seje menos confiável. O cabeçalho do UDP provê um campo destinado a verificação de erros, porém, o próprio protocolo apenas informa ao aplicativo que o pacote transferido naquele momento está corrompido ou não. Cabe à aplicação o controle de erro, propriamente dito.
Por favor, me corrijam se eu falei besteira! (-:
Luciano disse: "Mas assim que sair o reiser4 eu aplico o patch no kernel na hora. Ele é surpreendentemente mais rapido alem de fazer as coisas em formas de transações (ou a operaçao é totalmente realizada ou não é realiada)..."
Todos os sistemas de arquivos jornalados são assim. É para isso que serve o 'journal'.
Wconserta disse: "agora o que deveria nem ser mencionado de tão ruim que é o ext2"
O ext2 é um sistema de arquivo não-jornalado, o único do benchmark desse tipo. Entre os sistemas de arquivos desse tipo, ele é muito bom e bem rápido (e por isso mesmo não faz vergonha no benchmark). Para máquinas simples e com pouca memória que são reaproveitadas, acho que ainda é a melhor opção (menor sobrecarga de memória e processamento). Para clientes de terminal não há nem dúvidas, pois essas máquinas quase não trabalham com arquivos locais - apenas arquivos temporários - e utilizar um "journal" seria um gasto a mais injustificável.
Reiserfs RH/Fedora
http://www.linuxdicas.com.br/sections-viewarticle-258.html
JFS é ruim? Em muitos pontos ele se saiu bem nos testes,pareceu-me um meio termo interessante. Ele suporta Journal?
Abraço
JFS == Journaled File System. Precisa falar mais? =)
Olha, pelo que entendi e pela minha experiencia,
o ReiserFS é o melhor para uso desktop. Mas como o patola disse e o proprio artigo dispoe, tudo depende das necessidades...
Pessoas,
Uso os dois ReiserFS e ext3 e já tive problemas com ReiserFS, ele dá uns crashes as vezes... e fica scanneando o boot várias vezes.. isso é lento.. coisas que não acontecem com ext3.. mas até hoje não vi nada que comprometecem dados da empresa.
O teste em questão é mais um entre vários outros e a conclusão é mais ou menos semelhante dos outros testes:
http://oregonstate.edu/~kveton/fs/
http://bulma.net/body.phtml?nIdNoticia=1154
http://kerneltrap.org/node/view/715/3435
Eu uso XFS há uns 6 meses com excelente resultado, extremamente resistente aos apagoes, pois a checagem é feita na proria montagem e recover é muito rápido (dá de lavada no ext3 e reiserfs, os sistemas que já usei). Porém achei mais lento que reiserfs no acesso e escrita num típico desktop de escritório. Tem uma outra vantagem: apesar que a maioria dos usuários de Linux ignorarem a importancia de fragmentação, ela existe e compromete o desempenho do sistema (tá certo que muito menos do que FAT e VFAT). E diferente do reiserfs (para esse está sendo desenvolvido o defregmentador, segundo o Rans Reiser), XFS já tem seu defragmentador (eu nunca precisei usar).
Tem um artigo que achei muito interessante é:
http://www.osnews.com/story.php?news_id=69
Os p?oprios desenvolvedores falando do seu projeto e comparando com o projeto dos concorrentes.
Eu uso reiserfs amarradão, essa estória de ter problema com reiserfs pra mim não existe. Eu tive problema com o ext3 a ponto de perder o conteúdo do meu HD, numa época que comprei uma placa mãe com problemas, ela gerava travamento do sistema direto e só metendo o dedão do reset mesmo para resolver! nem o SysRq deu jeito! Era kernel panic mesmo! Nessa prova de fogo perdi um HD lotado de arquivos pessoais... então qeum disse que ext3 é bom? Para mim não é! Eu quero testar xfs, mas queria que o reiserfs4 saísse logo também...
Uma coisa é fato, esse cara é o maior mala, pois se colocasse esses gráficos em png seria menos pesado e com muito mais qualidade. Fiz um teste aqui e o png reduziu em 50% o tamanho do já pequeno jpg. Mas isso é para os gráficos, png com imagem/fotos fica bem maior que o jpg.
Falow!
Por favor me tirem uma dúvida.
Estou adquirindo um servido dell com HD SCSI, para rodar samba servindo um sistema clipper para uns 25 clientes. Vou instalar o Mandrake10.
Gostaria de utilizar ReiserFS. O que acham da minha escolha ? Deveria eu repensar o XFS ou JFS ?
marsguo, eu usaria reiserfs ou xfs. masmo usando um sistema com journaling, é sempre bom usar um no-brake para as emergência, pois mesmo que o sistema de arquivos aguente as pancadas, o hardware pode não agüentar :-P
Falow!
Sempre usei o reiser sem o menor problema (desde o conectiva 5). Mas de repente, (sem queda e energia ou qualquer outro motivo) com o Mandrake 10 perdi quase todo o filesystem (so sobrou o /tmp /usr e /boot. O fsck fez nem cosquinha. Fiquei meio desconfiado mas reinstalei, até agora tá legal.
Só que dias depois aconteceu a mesmíssima coisa com um colega meu: dançou feio com a dobradinha MDK 10 e reiser. MUITO preocupante.
Recomendo não usar essa dupla. O MDK é muito novo e o kernel 2.6 também. Agora vou esperar para ver se encontro por aí alguma coisa sobre este problema.
Este é o tipo de coisa que não adianta vir 50.000 pessoas falando que funciona maravilhosamente bem. Se meia dúzia se ferrarem sem explicação é preciso ficar atento.
Outra; o bom e velho ext2 e seu novo irmão ext3 estão sendo injustiçados. Principalmente o primeiro, que falando francamente é o campeão em robustez seguido de perto pelo seu irmão mais novo. Dificilmente se ouve falar que alguém perdeu um ext2. Já os outros se ouve falar com maior frequência.
PSANTOS, já tive alguns contra-tempos com ReiserFS, mas este sempre foi muito eficiente em restaurar o sistema. Caso fsck não dê conta do recado a solução é parir para reiserfsck --rebuild-tree. É demorado, mas a recuperação é quase 100% garantida se for realizada logo apos a queda do sistema. Vale lembrar que vem aí o ReiserFS4. No site http://www.namesys.com/benchmarks/v4marks.html tem uns testes comparativos.
Na empresa em que eu trabalho montei um servidor de impressão em cima de um 486 velhão que estava jogado num canto. Coloquei Conectiva 5 (isso tem uns 3 anos). O ext2 *nunca* apresentou nenhum problema mesmo com a máquina sendo desligada no dedão (power off) *todo santo dia*! A máquina não tem monitor, nem teclado ou maouse. É apenas um gabinete vertical com a impressora HL LaserJet em cima.
Conclusão: quem disse que o ext2 é uma vergonha? Performance ele tem, pois não tem o overhead das operações do 'jornal´, robustez também tem... pra mim tá ótimo. Claro que sou a favor da evolução, e pra servidores de missão crítica e estações de trabalho com disco muito grandes o jornal é um recurso interessante, pois após uma queda o sistema de arquivos não precisa ser checado (fschk), mas isso não exclui as vantagens de usar ext2 no lugar e hora convenientes.
A julgar pela quantidade de patches do time do XFS no kernel, em *toda versão*:
1) O XFS ainda tem _muitos_ bugs
2) O XFS vai se tornar excelente
Usava exclusivamente o XFS em uma máquina ligada em uma rede elétrica instável e toda vez que a energia acabava, na volta o XFS corrompia vários arquivos, inclusive arquivos de /var, coisas que provavelmente só estavam abertas para leitura, etc.
Gostava do XFS, era rápido e mesmo sendo enorme (em linhas de código), parecia deixar a máquina com um overhead de gravação de disco menor -- mas devido e esses "incidentes" resolvi voltar para o **bom** e velho ext2, que é rápido, estável, simples e robusto para a maioria das aplicações.
Ja perdi grande parte do conteudo do /etc e /bin usando o ext3 umas 4 vezes, quando acabou a luz aqui em casa, tanto que ate deixava um backup aqui pra nao ter que reinstalar o sistema, mas na 4 vez me enchi, formatei tudo pra reiserfs e ja estou a quase 1 ano rodando beleza, sem perder um arquivo.
__Nunca tive problemas com o ReiserFS, ele é bastante rápido, mas tem um delay durante o processo de boot, do seu log de recuperação(o journaling),depois é bem garantido.Problemas com o ext2 são frequentes comigo,embora recuperáveis. o ext3 me machuca ainda mais e uma instalação com o XFS que fiz uma vez no Slack 8.1, se foi pra nunca mais voltar. . .
Eu sou usuário desktop (mdk 9.1) e também uso o pré-histórico ext2...
Não concordo com as pessoas que acham o ext2 "vergonhoso". Há uma miriade de aplicacoes onde o journal é dispensável e velocidade é bem vinda (ex. "formatar" uma memory key usb ou qualquer dispositivo de armazenamento em memória)
Oi Patola... um sistema de arquivos ser "jornalado" nao significa que ele implementa transaçoes, tanto que o REISER4 eh o primeiro a implementar transaçoes (O que eh exatamente o que eu falei acima, eh igual a transacoes de um banco de dados).
Luciano, não foi isso que eu aprendi anos atrás. A idéia de um filesystem jornalado é justamente um que implemente transações! O journal nada mais é que o equivalente ao log de um banco de dados, usado para consistência de transações. Retirado de http://www.cafecomputer.com/journaling.htm:
Journaling filesystems
Waiting for a fsck to complete on a server system can tax your patience more than it should. Fortunately, a new breed of filesystem is coming to your Linux machine soon. Journaling filesystems maintain a special file called a log (or journal), the contents of which are not cached. Whenever the filesystem is updated, a record describing the transaction is added to the log. An idle thread processes these transactions, writes data to the filesystem, and flags each processed transaction as completed. If the machine crashes, the background process is run on reboot and simply finishes copying updates from the journal to the filesystem. Incomplete transactions in the journal file are discarded, so the filesystem's internal consistency is guaranteed.
This cuts the complexity of a filesystem check by a couple of orders of magnitude. A full-blown consistency check is never necessary (in contrast to ext2fs and similar filesystems) and restoring a filesystem after a reboot is a matter of seconds at most.
galera...
discordo desse teste,
um benchmark de filesystems jamais pode ser feito do jeito que foi feito!!!
como analisar recursividade de filesystems, sem se falar em IOps ou coisas do genero ?
pelo que sei .. todos benchmarks de filesystems,
sao feitos por processos que envolvem multiplos threads fazendo IO sequenciais e randomicos em arquivos de multiplos tamanhos..
isso sim mede a capacidade de um filesystem de saber qtos IOps se consegue fazer em diferentes tecnologias.. como SAN's ou entao SCSI3 mesmo.
ou entao testes como os testes padronizados pela IBM nos anos 80, de se medir qto tempo demora no filesystem para que o disco percorra 1/3 dos setores de trilhas estipuladas..
fazer tar, mkdir, mkfs.. nao mede a capacidade muito menos a performance de um filesystem
MUITO MENOS AINDA sua consistencia
vide textes de veritas filesystem, quick file system (da sun , para multiplas luns com blocksizes gigantes... pra fazer MAIS bytes em menos iops).
eh isso
abracos
inaddy :)
rafael,
Não sei se você leu o artigo, mas o autor deixa bem claro, ele está cansado de benchmark técnico, ele queria algo que nós usamos no dia-a-dia. Quem, no seu dia-a-dia, fica usando IO e IOps? Eu não vejo isso, na verdade ninguém vê os IO e IOps, as pessoas vêem o tempo que leva para descomprimir um arquivo tar ou para copiar vários arquivo de um backup.
Isso no meu ver é um benchmark funcional.
Claro que não desvalida o benchmark técnico, ou seja, em laboratórios especialiados para isso.
Falow!
Patola, acho que o que o Luciano quis dizer foi que o Reiser4 fará as transações de forma atômica.
Nos outros sistemas de arquivos pode ocorrer de, em caso de falha na energia, o "journal" ser atualizado mas o sistema de arquivos não. Ou vice-versa: o sistema de arquivos é modificado, mas o "journal" não é atualizado com essa transação.
Segundo o site oficial, o Reiser4 praticamente elimina esta possibilidade, uma vez que todas essas ações ocorrem ao mesmo tempo, e de forma interdependente. Ou seja, o sistema de arquivos é gravado somente se o "journal" for atualizado, e vice-versa. Por isso é usado o termo 'atômico': não se consegue separar a ação de atualizar o "journal" da ação de gravar no sistema de arquivos.
Por favor corrijam qualquer engano.
Um abraço,
NatuNobilis
Eu quero testar o BFS (ou BeFS) no Debian. Vamos aos testes...
http://befs-driver.sourceforge.net/
Também tive problemas com a dobradinha Mandrake 10 Official/ReiserFS. Usei Reiser em meu SuSE 8.0 por dois anos e não tive problema algum. O mandrake 10 com reiser nem instalava, travava quando ia instalar os pacotes no hd...tentei de tudo, até tentar ext3, que rodou perfeitamente, agora o por que? nem imagino...
Uso ext3 em servidores com alta disponibilidade e nunca houve problemas em relação a arquivos corrompidos, mas deixa um pouco a desejar em escrita de arquivos grandes ~2GB.
Recomendo o uso do ext3, mas atualmente estou testando XFS e me parece seguro e rápido, pelo menos nos testes iniciais.
Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.