Tunando sistemas de arquivos para GNU/Linux

O artigo tem o propósito principal de mostrar como "tunar" os sistemas de arquivos mais usados atualmente no GNU/Linux, deixando-os mais rápidos.

[ Hits: 62.757 ]

Por: Perfil removido em 31/07/2012


Benchmark básico depois de tunar os sistemas de arquivos para melhor desempenho



Depois de abordar como tunar cada sistema de arquivos citados no artigo, nada mais normal que testar o desempenho de cada um, para ver como cada um comporta-se diante dos testes.

E até porque, dada a curiosidade sobre como comportarão os sistemas de arquivos após as alterações no comportamento, não é mesmo? Mas, o melhor mesmo é usar no dia a dia, aí sim poderá ver realmente quais as vantagens ganhas.

Aqui, vou mostrar vários gráficos que comparam o desempenho de cada um, trata-se de benchmark básico.

Para esta série de testes de desempenho, usei uma máquina com:
  • Processador Intel® Core™2 Duo;
  • Placa mãe ASUS;
  • Memória RAM com capacidade 4 GB;
  • HD Samsumg SATA 3;
  • Sistema Debian 6.0.5;
  • kernel 3.2.0-0.bpo.2-amd64.

Todos os testes não informam o uso de CPU, apenas o tempo que foi necessário para concluir a tarefa, e foram feitos no prompt de comando.

As características usadas para cada sistema de arquivos que foram habilitadas para o benchmark:

- ReiserFS:
  • Journal externo;
  • As opções para alterar o comportamento ReiserFS foram adicionadas ao "/etc/fstab":

    notail,rw,data=writeback,relatime

- XFS:
  • Journal externo, criado com o seguinte comando:

    # mkfs.xfs -f -l logdev=/dev/sdb2,size=1g -d agcount=4 -i maxpct=5 /dev/sda8

  • As opções para alterar o comportamento para XFS foram adicionas ao "/etc/fstab":

    rw,relatime,attr2,nobarrier,allocsize=64m,logdev=/dev/sda7

- JFS:
  • Journal externo;
  • As opções para alterar o comportamento para JFS foram adicionadas ao "/etc/fstab":

    rw,relatime

- ext3:
  • Journal externo, o tamanho do journal criado é de 105500;
  • As opções para alterar o comportamento para ext3 foram adicionadas ao "/etc/fstab":

    errors=continue,rw,relatime,commit=30
    E alterei o modo de operação para writeback, usando o comando abaixo:

    # tune2fs -o journal_data_writeback /dev/sda8

- ext4:
  • Journal externo, o tamanho do journal criado é de 105500;
  • As opções para alterar o comportamento para ext3 foram adicionadas ao "/etc/fstab":

    errors=remount-ro,rw,relatime,commit=30


    E alterei o modo de operação para writeback usando o comando abaixo:

    # tune2fs -o journal_data_writeback /dev/sda8

Primeiro teste

Trata-se de criar trinta mil arquivos de texto comum, sem nenhum conteúdo usando o comando touch. Para isso, desenvolvi um script para fazer todo o trabalho e todos o sistemas de arquivos concluíram o trabalho em poucos segundos.

Veja no gráfico abaixo o resultado:
Veja no gráfico, que ext4 e ext3 foram respectivamente os mais rápidos, seguido por ReiserFS, logo após JFS e por último XFS. Mas lembre-se que XFS não trabalha bem com arquivos pequenos, e sim com arquivos grandes.

Segundo teste

Trata-se de listar todos os trinta mil arquivos criados anteriormente. Todos os F.S. concluíram o trabalho em poucos segundos.

Veja no gráfico abaixo o resultado:
Veja que, mesmo todos usando o journal externo, o ReiserFS foi o mais rápido, seguido por JFS e XFS, ext3 e ext4 foram os mais lentos neste teste.

Terceiro teste

Trata-se da remoção de todos os trinta mil arquivos criados anteriormente, usando o comando rm. E mais uma vez, a conclusão da tarefa foi feita em poucos segundos.

Veja no gráfico abaixo o resultado:
Veja que, mais uma vez o XFS mostrou que não trabalha bem com arquivos pequenos e foi o último com um tempo bem acima dos outros sistemas de arquivos. Os mais rápidos foram ext3 seguido de ext4 e ReiserFS. O JFS não saiu-se bem no teste, pois o mesmo não trabalha bem com arquivos pequenos também.

Quarto teste

Trata-se da gravação de um arquivo de 1,3 Gigabytes de tamanho, e todos os sistemas de arquivos testados acabaram o trabalho em segundos.

Veja no gráfico abaixo o resultado:
Os sistemas ext4 e XFS foram, respectivamente, mais rápidos que os outro F.S. neste teste.

Quinto teste

Trata-se de empacotar e compactar usando o comando tar zcf o arquivo de 1,3 Gigabytes de tamanho, gravado anteriormente. Todos levaram quase um minuto para concluir o trabalho.

Veja no gráfico abaixo o resultado:
Neste teste, JFS e XFS foram os mais rápidos, respectivamente. ReiserFS foi o mais lento de todos.

Sexto teste

Trata-se de desempacotar e descompactar o arquivo compactado e empacotado anteriormente de 1,3 gigabytes. Mais uma vez, todos concluíram o trabalho em segundos.

Veja no gráfico abaixo o resultado:
XFS foi o mais rápido outra vez, comprovando que com arquivos grandes ele trabalha bem, ext4 foi o segundo mais rápido, seguido de ext3 e JFS. ReiserFS foi o que levou o maior tempo.

Sétimo teste

Trata-se do tempo levado para remover o arquivo de 1,3 Gigabytes gravado no teste anterior. O trabalho foi concluído em segundos.

Veja no gráfico abaixo o resultado:
O mais rápido neste foi JFS, terminando a remoção do arquivo em incrível um milésimo de segundo, seguidos de ReiserFS e ext4.

Oitavo teste

Trata-se de criar trinta mil diretórios usando o comando mkdir. Para isso, desenvolvi um script para este trabalho e o tempo de conclusão para todos os sistemas de arquivos foi em segundos.

Veja no gráfico abaixo o resultado:
ReiserFS foi o mais rápido na criação dessa avalanche de diretórios, seguido de XFS e JFS. Os ext3/4 ficaram para trás neste teste.

Nono teste

Trata-se de listar os trinta mil diretórios criados anteriormente. Todos acabaram o trabalho de listagem em segundos.

Veja no gráfico abaixo o resultado:
ReiserFS foi o mais rápido outra vez, seguido de JFS e XFS, que finalizaram o trabalho com o mesmo tempo. O ext4 foi o que levou mais tempo.

Décimo teste

Trata-se de remover todos os diretórios criados anteriormente. Todo o trabalho foi concluído em poucos segundos em todos o sistemas de arquivos testados.

Veja no gráfico abaixo o resultado:
Neste último teste, os mais rápidos foram ext3 e ext4, respectivamente. ReiserFS demostrou um ótimo desempenho também. XFS foi o que levou mais tempo para concluir o trabalho.

Nota-se neste benchmark básico, que alguns sistemas de arquivos, como XFS e ReiserFS, demostraram suas características. XFS com um desempenho muito bom para arquivos grandes e ReiserFS para arquivos pequenos.

Dá para perceber também, que alguns sistemas de arquivos tiveram melhor desempenho com journal externo do que outros.

Veja o ext3/4, teve em alguns testes, um desempenho abaixo do esperado, mas lembre-se de que a maioria dos testes foram feitos com trabalhos em massa, e que nem todas as características foram habilitadas em todos os sistemas de arquivos testados.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Opções de montagem e vantagens e desvantagens de usar journal externo
   3. Tunando o sistema de arquivos ReiserFS
   4. Tunando o sistema de arquivos XFS
   5. Tunando o sistema de arquivos JFS
   6. Tunando os sistemas de arquivos ext3 e ext4
   7. Benchmark básico depois de tunar os sistemas de arquivos para melhor desempenho
   8. Considerações finais
Outros artigos deste autor

Adaptador Bluetooth no Slackware

Construindo um portscanner TCP com Python

Instalando EpiInfo 6.0.4d no Slackware 10.2

Pós-instalação do Arch Linux

Por que Gentoo é diferente?

Leitura recomendada

Captive-NTFS com kernel 2.6

Configuração do Samba no Debian Server

Diferenças entre o sistema de arquivos do Windows e Linux

GIT: Controle de versões distribuído para projetos de software

PersonalBackup - Ferramenta de backup via web

  
Comentários
[1] Comentário enviado por albfneto em 31/07/2012 - 10:51h

Excelente artigo, e existem poucos sôbre o assunto.
Favoritado.

[2] Comentário enviado por danniel-lara em 31/07/2012 - 11:54h

Parabéns pelo Artigo
ficou muito bom mesmo
é isso ai

[3] Comentário enviado por madtrek em 31/07/2012 - 12:01h

"tunando" ?!?!?

Pelo amor de deus, não cometa assassinato da língua Portuguesa !!!

Ajustando !!!!

Nada contra usar anglicismos quando não existe uma palavra em Português equivalente, mas neste caso a palavra existe !!!!!

Fábio Rabelo

[4] Comentário enviado por removido em 31/07/2012 - 12:53h

O termo tunar é originário da palavra estrangeira tunning que significa “ajustar” como foi dito pelo colega madtrek na sua critica.

Apesar dessa palavra ainda não está em dicionário esse termo é muito usado, quando se personaliza um carro, moto, computador e etc. e acredito que o mesmo será adicionado em futuro. por isso usei tal palavra.

No mais obrigado pelos comentários.

[5] Comentário enviado por alefesampaio em 31/07/2012 - 18:33h

Isso mesmo Abreu acho que toda critica devem ser direcionada no sentido do artigo quanto ao embasamento filosófico tais como: domínio do tema, conteúdo,

Teu artigo estar muito bom parabéns.


Abraço.

[6] Comentário enviado por galactus51 em 31/07/2012 - 21:17h

Olá Edson. Parabéns pelo artigo, Gostei que pelo menos você colocou o link dos meus três artigos sobre sistemas de arquivos ( ext4, XFS e JFS) nas referências!

[7] Comentário enviado por removido em 31/07/2012 - 21:42h

Olá amigo galactus51.

Seus três trabalhos foram usados como algumas das referências para conclusão do artigo. pois contém um bom conteúdo e bem claro. Sobre os textos das suas publicações, alguns trechos (por estarem bem explicados) me servirão de inspiração para desenvolver e explicar alguns assuntos, mas não fiz cópias do seu trabalho.

Obrigado alefesampio e galactus51 pelos comentários.

[8] Comentário enviado por galactus51 em 01/08/2012 - 00:10h

Grande Edson! Sei que não fez cópia do meu trabalho, como você mesmo disse, te ajudaram a explicar as coisas melhor. É que muitas pessoas tem o hábito de fazer artigos e não colocar as fontes!

[9] Comentário enviado por removido em 01/08/2012 - 09:17h

Olá.

Na explicação do ReiserFS: há como calcular quanto deve ser deixado para a partição de journaling?

2GB não é muito? Até tendo em vista hibernação um valor desses é contestado para swap, sendo aqui o caso muito diferente.

[10] Comentário enviado por removido em 01/08/2012 - 09:21h

Tranquilo galactus51 !

E quanto ao seu trabalho servir. tenha em mente que sempre o conhecimento postado em qualquer site vai ajudar as pessoas que precisam do conteúdo.

Abraço e bem vindo ao VOL!

[11] Comentário enviado por removido em 01/08/2012 - 09:57h

Bom dia amigo Listeiro_037.

O calculo é o seguinte em sistemas de arquivos que tem em seus blocos o tamanho de 4kbytes o padrão é 8193 blocos reservados. então ficaria:

4*8193/1024 = 32 megabytes para o journal, pois são blocos de 4 kilobytes de tamanho vezes a quantidade de blocos por padrão dividido por 1024Kbytes que é 1megabyte.

Como no máximo o comando pode atribuir 32749 blocos de espaço para o journal em blocos de tamanho 4 kbytes o tamanho total e máximo vai ficar em torno de 126 megabytes.

Nunca calculei usando o tamanho de bloco diferente e sempre usei o tamanho padrão (4096) pelo comando mkreiserfs, mas caso altere o tamanho do bloco para o tamanho máximo que é de 8kbytes creio que não chegue nem a 1Giga de espaço reservado para armazenamento do journal.

Quanto aos 2G depende do sistema de armazenamento que usa.

[12] Comentário enviado por marcrock em 01/08/2012 - 10:00h

Muito bom !!! Eu sempre uso ReiserFS ou Ext4 no meu desktop. O ReiserFS lida bem com arquivos pequenos e é confiável.

[13] Comentário enviado por chimico em 10/08/2012 - 22:23h

@eabreu
Parabéns pelo belo artigo, eu apliquei a otimização no ext4 usando a distro Toorox (baseada em gentoo). Vou testar no Siduction.
Ficou bala, eu sempre uso uma partição para o sistema e outra para o /home. Criei uma partição de 128 MB para cada journaling e ao invés de usar o comando

mke2fs -O journal_dev /dev/sdb1 -b 4096 -L journal-ext-sda1 105500

usei somente

mke2fs -O journal_dev /dev/sdb1 -b 4096 -L journal-ext-sda1

porque o primeiro dava erro, algo como "sistema de arquivos aparentemente maior que a partição suporta"

A máquina em questão é um athlon-xp 2000+ com 1G de Ram. Curiosamente já usava partições JFS com jornal externo, mas no meu hardware não ficou leve ou estável.

[14] Comentário enviado por removido em 30/01/2013 - 16:34h

Olá. Depois do artigo ainda tive estas dúvidas, mas ainda não cheguei a alguma conclusão.

Gostaria de saber até quando um arquivo seria considerado "pequeno" e qual seria o melhor sistema de arquivos para criar uma partição /tmp (ou /var/tmp, /var/log) separada.

[15] Comentário enviado por removido em 30/01/2013 - 17:29h

Para diretórios como: /tmp, /var/tmp e /var/log que normalmente se armazena arquivos pequenos (é raro ter arquivos grandes), seria um sistema de arquivos como o ext3/4 ou reiserfs. de preferência pelo ext3 ou ext4, pois num futuro próximo ou distante poderá migrar os sistemas de arquivos exts (3 ou 4) para o btrfs (que promete ser bem completo).

Na minha opnião se o diretório trabalha com muitos arquivos com mais de 50 megabytes não usária o sistema de arquivos ext3/4 ou reiserfs e sim o xfs. Mas para fins de estudo e aprofudamento de conhecimento faça benchmarks. Caso queira fazer alguns testes de desempenho use a ferramenta Phoronix Test Suite.

[16] Comentário enviado por elton.linux em 21/04/2013 - 01:50h

Boa noite a todos,

dúvida ridícula, o que é considerado arquivo pequeno e arquivo grande?
Uma música em mp3 é pequeno?
... qual parâmetro para essa medição

abraço

[17] Comentário enviado por gabrielbiga em 11/09/2013 - 10:18h

Irrelevante a crítica sobre o título do artigo. "tunar" é super utilizado e compreensível até no meio corporativo, assim como "setar", "startar", "debugar" e entre tantos outros.
Artigo incrível! Parabéns.

[18] Comentário enviado por removido em 13/04/2018 - 05:19h

o link de referência "Aumento de 40% na velocidade do ReiserFS" tá apontando somente pra "http://" e não pro site inteiro

https://www.vivaolinux.com.br/dica/Aumento-de-40-na-velocidade-do-ReiserFS


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts