| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | #!/usr/bin/perl
srand( time() );
@fss = ( "Ext2", "RaiserFS", "XFS", "UFS", "Add your own FS here" );
foreach $fs (@fss) {
printf "%s: (RD)%d ms, (WR)%d ms, (SEEK)%d ms\n", $fs, rand(2)*1000, rand(3)*1000, rand(1)*1000;
}
Estou apenas a tentar demonstrar como qualquer benchmark deste tipo e' inutil -- existem 1,000,000 de factores que tornam as benchmarks a FS's perfeitamente irrelevantes a nao ser que se tenha um ambiente de laboratorio muito bem controlado. Alem disso muitos dos FS's mencionados suportam funcionalidade que alguns outros nao (e.g., XFS - stripping), o que significa que em alguns casos estamos a comparar alhos com bugalhos... Alguns factores que fazem qualquer benchmarking distribuido irrelevante sao: - Cache nos discos
- IDE vs SCSI
- SCSI1 vs SCSI2
- Wide SCSI vs Narrow SCSI
- DMA access vs Non-DMA access
- Memoria no kernel dedicada a cache de disco
- Memoria total na maquina
Qualquer pessoa que conheca bem como os filesystems funcionam consegue fazer o tuning a uma maquina por forma a que pareca que o FS voa! Basta aumentar a memoria reservada para buffers, ou aumentar o tamanho da cache do disco. Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
|
| | | | | | | Não nego a verdade do que dizes, mas penso que consideres uma coisa: A mim, como utilizador normal, interessam-me apenas as benchmarks aplicadas na minha máquina, ou em máquinas semelhantes também com uma utilização semelhante. Se alguém se der ao trabalho de comparar os diversos filesystens nuna situação semelhante à minha, ficarei-lhe muito grato e terei essa comparação em mente quando for decidir o que instalar. Outra maneira de ver: Se na minha máquina se comportar melhor o XFS que o ReiserFS, ou até o Ext2 que qualquer outro filesystem, então não será por uma comparação científica que me mostre o contrário que mudarei de ideias, pois o meu caso é pessoal e demonstrado pelo uso que dou á máquina, por isso, para mim, tem mais validade o meu "estudo" que o estudo verdadeiramente científico. Como refiro um uso pessoal, também posso referir um uso de servidores. Apenas mudam as subtilezas.
hugs
Strange |
| | | | | Em vez de penso é peço, claro.
hugs
Strange |
| | | | Hummm podes fazer os testes no mesmo disco no mesmo computador e com a mesma swap, não é preciso um ambiente de laboratório. É só preciso um bocado de trabalho e imaginação.
|
| | | | Concordo se o objectivo fossem resultados totais, mas aqui serao mais resultados relativos entre os varios fs com a mesma maquina/kernel/etc (parecida com a que temos em casa ...)
Cump
|
| | | | ok!
Cá vão os resultados do meu teste seguindo um método absolutamente não científico:
Acção:
Descompressão de uma tarball de backup em ext2fs e em xfs;
A tarball tinha 3,473,058,675 bytes.
Era constituída à vontade em cerca de 99% por ficheiros de shares do Samba, e devia ter uns bons ziliões de ficheiros;
Comando: tar -Ixpvf backup-tux.tar.bz2;
Hardware:
Máquina: DELL PowerEdge 1300;
PIII/700;
512 MB ram;
HD SCSI IBM DPSS-318350N, Adaptec AIC-7890/1;
Resultados com ext2fs:
Início: 16:12:50
Fim: 17:01:16
Tempo: 00:48:16
Resultados com xfs:
Início: 17:12:15
Fim : 18:02:51
Tempo : 00:50:36
Conclusão: Em ext2fs, 48m:16s
Em xfs, 50m:36s
Mário Gamito
educação, ensino |
| | | | | | | 17:01:16-16:12:50 = 61276-58370 = 2906 = 48:26 18:02:51-17:12:15 = 64971-61935 = 3036 = 50:36 3036/2906 = 1.0447 = +4.47% (+2m10s) Poderás também comparar qt tempo demora a remoção desses "ziliões" de ficheiros? Outro teste seria que poderias fazer seria a descompactação do kernel 2.4.4, (cp conf arch/i386/defconfig), yes | (make dep && make bzImage && make modules), rm -fr linux. De qq modo, obrigado pelo trabalho q tiveste.
hugs
Strange |
| | | | A minha opinião sobre estes testes é a seguinte:
1 - Tas a fazer a descompressão do bzip2 simultaneamente. O CPU está ocupado a 99% com isso, e por esse motivo, qualquer fs que necessite de algum algoritmo mais evoluido sai penalizada. Julgo que nesta situação, o ReiserFS sairia também bastante penalizado. O ext2, como é straightforward, é o que sai mais beneficiado por o CPU poder dispensar poucos ciclos para o fs, visto que é o que tem que fazer menos coisas. Neste caso concreto, até a FAT32 era capaz de ter valores aproximados. Se conseguisses fazer apenas o tar, era melhor.
2 - Com tamanha quantidade de dados, e apenas escritas, qualquer algoritmo inteligente de caching só prejudica, visto que tens o overhead de gestão de caching e nenhum proveito. Os dados a escrever são sempre novos, nunca ha' leituras, seeks, etc.
3 - Não sei se os ziliões de ficheiros que tinhas estavam muito espalhados por muitas directorias ou se tinhas imensos ficheiros numa directoria. O ext2 porta-se mesmo muito mal quando tem milhares de ficheiros na mesma directoria. E o XFS?
No entanto ainda assim acho impressionante. Mesmo nesta situação pouco vantajosa para o XFS, e que em nada reflecte a utilização normal diária do fs, o XFS foi apenas 0.4% mais lento. Tendo em atenção os benefícios adicionais que este tém, acho que não há dúvidas da vantagem da sua utilização. Já pensaste em fazer um power off a meio desse teste nos dois filesystems? :))
|
| | | | Um power-off ?? Ele assim vai despedaçar a ext2 toda... e no minimo uns valentes minutes a correr o fsck.ext2, e o xfs arranca muito mais rapido e com maior grau de consistencia... Isso seria um teste injusto...
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | ...mas mostra pelo menos *uma* vantagem do xfs ;)
nuno aka ratao
Regards, Nuno Silva aka RaTao |
| | | | Viva!
Sim, o teste estava longe de ser o ideal.
Simplesmente aproveitei uma coisa que tinha mesmo que fazer (repôr uma /home completa) e resolvi comparar com os dois filesystems.
E tu com o postgres?
Anyway, mesmo que em tese o xfs possa ter performances, digamos, semelhantes ao ext2fs, as suas capacidades adicionais compensam largamente.
Mário Gamito
educação, ensino |
| | | | Essa benchmark não ajuda muito, ou mesmo quase nada. normalmente as benchmarks que se fazem incidem em dois niveis o acess time e o tempo que demora a copiar um ficheiro grande. A descompressão envolve outros recursos para alem do sistema de ficheiros. Se quiseres fazer outro teste exprimenta copiar um ficheiro grande +200 megas e alem disso exprimenta copiar varios ficheiros pequenos, quantos mais ficheiros e mais pequenos foram melhor.
|
| | | | ok, para quem conhece o bonnie++ aqui estão os copy+paste.
a maquina é um
p3-866
256mb ram
disco ultra dma ide 30gb
xfs:
nuno@mouse:~$ /usr/sbin/bonnie -d /usr/tmp/ -n1 -x1
mouse,496M,11310,97,34953,23,11289,8,9472,79,31252,10,126.7,0,1,780,16,+++++,+++,+++++,+++ ,1776,32,+++++,+++,+++++,+++
ext2:
nuno@mouse:/tmp$ /usr/sbin/bonnie -d /usr/tmp/ -n1 -x1
mouse,496M,11338,98,36575,24,11066,8,10031,84,31345,10,132.9,0,1,882,11,+++++,+++,+++++,++ +,1312,20,+++++,+++,+++++,+++
como os resultados sao tao evidentes nem faço comentarios :)
nuno aka ratao
Regards, Nuno Silva aka RaTao |
| | | | | | E para quem não conhece o bonnie++? ;-)
Isso em português (ou inglês, não sou esquisito :-P) quer dizer o que mesmo? :-)
Já agora... tu que já experimentaste o xfs no linux... Achas que para "uso caseiro" vale a pena? (para quem usa o pc essencialmente para a função "desktop"). E já agora se já tiveres experimentado reiserfs a pergunta repete-se.
Cumprimentos,
Bruno Gravato.
|
| |
|
