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: 63.757 ]

Por: Perfil removido em 31/07/2012


Tunando os sistemas de arquivos ext3 e ext4



Aplicarei a prática de tunar os sistemas de arquivos ext3 e ext4 na mesma página, pois o procedimento é igual para ambos os F.S. Usarei o journal externo e interno para ambos.

Mas não aplicarei as alterações antes da instalação do sistema operacional usado, e sim depois da instalação. Pois além de ser possível, é viável, já que muitos administradores de sistemas e usuários usam estes sistemas de arquivos como padrão em suas instalações.

Apresentando particionamento usado para aplicar as alterações:
  • Partição: /dev/sda1 com sistema de arquivos ext3 - Diretório root "/";
  • Partição: /dev/sda2 com sistema de aquivos ext4 - Diretório home "/home";
  • Partição: /dev/sda5 - Swap;
  • Partição: /dev/sdb1 - Partição usada para armazenar o journal externo da partição /dev/sda1;
  • Partição: /dev/sdb2 - Partição usada para armazenar o journal externo da partição /dev/sda2.

Caso tenha um particionamento diferente em sua máquina e/ou servidor, poderá fazer as operações do mesmo jeito. Porém, aconselho que antes de aplicar as alterações em uma máquina que está em produção, faça em uma máquina de testes, para poder avaliar quais alterações podem adequar- se às suas necessidades.

Tunando o ext3 e ext4 usando journal externo

Usando este esquema de particionamento apresentado e supondo que a instalação já foi feita com sucesso, vamos às alterações necessárias para usar journal externo. Tenha em mãos um LiveCD para executar os passos seguintes.

1. Certifique-se que o sistema de arquivos onde está instalado o sistema esteja desmontado. E em seguida, verifique o tamanho do bloco das partições do sistema usando os comandos descritos abaixo:

# tune2fs -l /dev/sda1 |grep -i "block size"
# tune2fs -l /dev/sda2 |grep -i "block size"
É necessário saber qual o tamanho do bloco do sistema de arquivos de cada partição que terá seu journal externo, porque cada partição que armazenará os logs precisará ter o mesmo tamanho de bloco.

2. Prepare as partições que receberão os journals:

# mke2fs -O journal_dev /dev/sdb1 -b 4096 -L journal-ext-sda1 105500
# mke2fs -O journal_dev /dev/sdb2 -b 4096 -L journal-ext-sda2 105500
As opções passadas ao comando mke2fs foram:
  • -O : Esta opção indica que irá ser adicionado e/ou removido do sistema de arquivos características específicas, ou seja, será habilitado alguns comportamentos com personalização. Diferentemente de quando usa-se os padrões na aplicação de uma sistema de arquivos.
  • journal_dev: Indica qual partição será preparada e usada para armazenar o journal de outra partição.
  • -b: Indica o tamanho do bloco do sistema de arquivos criado. Neste caso, o tamanho do bloco deve ser o mesmo da partição que contém o sistema, pois estas partições "/dev/sdb1" e "/dev/sdb2" irá armazenar os journals das partições "/dev/sda1" e "/dev/sda2".
  • -L: Este parâmetro é opcional, pois o mesmo adiciona um rótulo, ou seja, um nome da partição para identificação.

E por fim, o número indicado no fim é o tamanho do journal em blocos. Para calcular corretamente o tamanho do journal armazenado, tenha em mente que foi usado 4096 bytes de tamanho para cada bloco, que equivale a 4 kbytes para cada. No comando anterior especifiquei 105500 blocos reservados para o journal, e cada bloco com o tamanho de 4096 bytes (4 kilobytes) configurado na linha de comando. Então o tamanho do log é: 105500 x 4 / 1024, que equivale um pouco mais de 412 megabytes.

3. Agora, faça o ext3 e ext4 não terem mais journal interno, para poderem usar os que foram criados anteriormente.

# tune2fs -O ^has_journal /dev/sda1
# tune2fs -O ^has_journal /dev/sda2
Verifique se as partições ainda têm journal:

# tune2fs -l /dev/sda1 | grep -i has_journal
# tune2fs -l /dev/sda2 | grep -i has_journal
Veja na imagem anterior, que os dispositivos não tem mais journal.

4. Anexe os journals das partições para "/dev/sda1" e "/dev/sda2" às partições que armazenaram o journal de ambas.

# tune2fs -j -J device=/dev/sdb1 /dev/sda1
# tune2fs -j -J device=/dev/sdb2 /dev/sda2
Execute os comando abaixo, e veja a nova localização dos journals para "/dev/sda1" e "/dev/sda2":

# tune2fs -l /dev/sda1 | grep -i journal
# tune2fs -l /dev/sda2 | grep -i journal
Depois das alterações, veja como ficaram as partições que receberam os logs:
Tanto ext3 quanto ext4 usados nas partições do sistema, já estão rápidos com o logo externo, mas podemos deixar mais rápido ainda, fazendo uso do comando tune2fs ou do arquivo "/etc/fstab" para habilitar os modos de operação que os sistemas de arquivos ext3/4 possuem.

O padrão é ordered, assim como podemos habilitar outros comportamentos para os sistemas de arquivos usados.

Farei uso arquivo "/etc/fstab" para aplicar estes comportamentos.

No exemplo abaixo, estou indicando no ext3 (partição raiz) e ext4 (partição /home), que o modo de operação é writeback executando o comando tune2fs e adiciono a opção relatime fazendo com que tenha um ganho de desempenho muito bom para ambos os F.S.:

# tune2fs -o journal_data_writeback /dev/sda1
# tune2fs -o journal_data_writeback /dev/sda2


UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a /     ext3    errors=remount- ro,relatime    0    1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home    ext4    errors=continue,rw,relatime    0   &nbs p;2


Veja que o comportamento passado anteriormente, principalmente passado pelo comando tune2fs alterando o modo de operação 'data=writeback', faz com ambos os F.S. fiquem mais vulneráveis à perda de dados caso ocorra algum erro no sistema, e o mesmo seja forçado a ser desligado de forma incorretamente. Mas, a perda de dados é mais para o arquivos abertos.

Por exemplo, você está editando um arquivo e no momento em que está fazendo a edição, falta energia, então, o conteúdo que não foi salvo, será perdido.

No exemplo abaixo, deixo ambos os F.S. com maior desempenho, mas deixando a desejar na consistência:

# tune2fs -o journal_data_writeback /dev/sda1
# tune2fs -o journal_data_writeback /dev/sda2


UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a /     ext3   errors=remount- ro,noatime,nodiratime,barrier=0,commit=40    0    1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home     ext4   errors=continue,rw,noatime,nodiratime,barrier=0,commit=40     0    2


Observe que, além de estar usando o modo de operação writeback, estou passando para o sistema de arquivos que não serão gravadas atualizações de acesso a arquivo e nem a diretórios, assim, como também desabilito o barrier que dá mais desempenho.

Porém, deixa ext3 e ext4 com menos consistência, deixando seu sistema de arquivos mais vulnerável caso ocorra, por exemplo, quedas de energia.

Mas, uma característica ainda não abordada neste artigo e que acrescentei acima, é a commit.

commit

Os sistemas de arquivos ext3/4 podem ser configurados para sincronizar os dados e metadados a cada "n" segundos para o journal. Sendo que o valor padrão é 5 segundos. Isto significa que, se usar o valor padrão que é 5, e sua máquina é desligada incorretamente, como por exemplo em uma queda de energia, você irá perder apenas os últimos 5 segundos de trabalho, isto é, se o seu sistema de arquivos não for danificado.

Mas graças ao journaling, este risco é diminuído. Se aumentamos o valor, o sistema de arquivos ficará mais rápido já que o intervalo de sincronização e acesso ao journaling irá aumentar e não será necessário fazer tantas sincronizações em pouco tempo.

Porém, se deseja deixar seu sistema de arquivos ext3/4 o mais consistente possível, perdendo muito desempenho, acrescente ao "/etc/fstab", as seguintes opções:

# tune2fs -o journal_data /dev/sda1
# tune2fs -o journal_data /dev/sda2


UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a /     ext3   errors=remount- ro,barrier=1,sync    0    1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home     ext4  errors=continue,rw,barrier=1,sync    0   &nbs p;2


Veja bem estas opções de montagem, pois seu sistema de arquivos ficará muito lento, mas em compensação, estará mais consistente.

Uma boa forma de colocar seu sistema de arquivos ext3/4 ao meio termo, bom desempenho com consistência, seria usar as seguintes opções de montagem:

# tune2fs -o journal_data_writeback /dev/sda2

UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a /     ext3  errors=remount- ro,barrier=1    0    1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home     ext4  errors=continue,rw,barrier=1,commit=30    0  &nbs p; 2


Assim, mesmo com menos comportamentos habilitados e desabilitados, seu F.S. terá bom desempenho, pois ainda tem journal externo.

* Observação Importante: Caso a partição que contém o journal do sistema fique danificada e não possa mais ser acessada, ou o disco que contém o journal chegue ao fim de sua vida útil, seu sistema não poderá mais ser acessado, nem mesmo através de outros sistemas presentes no disco ou LiveCDs.

Para resolver isso, basta executar os seguintes comandos abaixo, para deixar seu sistema com journal e acessível mais uma vez. Mas antes, instale um novo disco que conterá a partição que irá armazenar o journal do sistema.

Supondo que o dispositivo que contém o sistema é "/dev/sda1", e o novo dispositivo que irá armazenar o journal é "/dev/sdc1". Lembre-se de criar uma tabela de partições para o novo disco e uma partição.

Primeiro, liste o tamanho do bloco do sistema de arquivos que contém o sistema:

# tune2fs -l /dev/sda1 |grep -i "block size"

Em seguida, prepare a partição que receberá o log do sistema de arquivos que contém o sistema, usando o tamanho do bloco que foi obtido pelo comando anterior. Abaixo, estou supondo que é 4096, se for diferente:

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

Em seguida, retire o journal do sistema de arquivos que tem o sistema, e crie o novo journal usando os comandos:

# tune2fs -O ^has_journal /dev/sda1
# tune2fs -j -J device=/dev/sdc1 /dev/sda1


Veja que já usei estes comandos no inicio da página, mas não custa nada voltar a usá-los, principalmente quando é necessário recriar o journal.

Lembre-se que os logs armazenam informações para recuperar dados do seu sistema, então, se o seu sistema tiver alguma informação corrompida, ou que precisa recuperar, após a criação do novo journal a informação não poderá mais ser recuperada.

Tunando o ext3 e ext4 usando journal interno

Para tunar o ext3 e ou ext4 com journal interno é mais fácil. Podemos usar comandos assim como usados anteriormente e o arquivo "/etc/fstab" para isso. Usarei o mesmo esquema de particionamento usado com journal externo.

Primeiro, vamos mudar o modo de operação via comando, e fazer com que ambos os sistemas de arquivos trabalhem em modo writeback:

# tune2fs -o journal_data_writeback /dev/sda1
# tune2fs -o journal_data_writeback /dev/sda2


Como já alterei via comando o modo de operação, não será necessário alterar no "/etc/fstab", mas mesmo assim acrescentarei algumas opções interessantes já explicadas.

UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a / ext3 errors=remount-ro,relatime 0 1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home ext4 errors=continue,rw,relatime 0 2


Para o kernel tratar o sistema de arquivos ext3/4, que contém o diretório root (raiz) no modo de operação alterado, no caso para writeback, teremos que incluir uma opção ao GRUB.

Se tem mais de um sistema com ext3/4 no seu diretório raiz "/" e deseja mudar o modo de operação apenas para alguns, então edite o arquivo de configuração e coloque ao final da linha a opção:

rootflags=data=writeback


Mas, se deseja incluir em todos os sistemas que usam ext3/4 no seu diretório raiz "/", então edite o arquivo "/etc/default/grub", usando seu editor favorito e deixe a linha abaixo:

GRUB_CMDLINE_LINUX=""

Assim:

GRUB_CMDLINE_LINUX="rootflags=data=writeback"


E em seguida, execute como root o comando:

# update-grub

Depois disso, o seu kernel tratará o sistema de arquivos no modo writeback, caso precise alterar o modo de operação para outro journal (data), e/ou ordered, precisará fazer as mesmas alterações no mesmo arquivo, isto porque o sistema de arquivos já teve seu comportamento alterado com o comando tune2fs.

Porém, se deseja alterar o modo de operação em sistema de arquivos ext3/4 de qualquer partição que contém qualquer diretório, com exceção do raiz, não precisará fazer tais alterações nos arquivos editados anteriormente.

* Lembrando que isso só vale para F.S ext3/4 com journal interno.

Para deixar o F.S. ainda mais rápido, mas deixando a consistência do mesmo mais vulnerável, principalmente usando a opção barrier, deixe seu fstab como descrito abaixo. E se ainda não mudou o modo de operação para writeback, execute o comando abaixo e faça as alterações já explicadas:

# tune2fs -o journal_data_writeback /dev/sda1
# tune2fs -o journal_data_writeback /dev/sda2


UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a / ext3 errors=remount-ro,noatime,nodiratime,barrier=0,commit=40 0 1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home ext4 errors=continue,rw,noatime,nodiratime,barrier=0,commit=40 0 2


* Não esqueça de alterar o arquivo "/etc/default/grub" e/ou alterar manualmente o arquivo de configuração do GRUB.

Mas, se deseja deixar o sistema de arquivos "/ext3/4" mais robusto perdendo desempenho, mude o "/etc/fstab" para o indicado abaixo, e altere o modo de operação usando o comando tune2fs.

No exemplo abaixo, deixo ambos os F.S. com mais desempenho, mas deixando a desejar na consistência:

# tune2fs -o journal_data /dev/sda1
# tune2fs -o journal_data /dev/sda2


UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a / ext3 errors=remount-ro,barrier=1,sync 0 1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home ext4 errors=continue,rw,barrier=1,sync 0 2


Nesta última forma de uso explicada, teria que mudar o arquivo de configuração do GRUB, e colocar no final da linha que descreve a localização do kernel a seguinte linha:

rootflags=data=journal


Ou, editar o arquivo "/etc/default/grub" usando seu editor favorito e alterar a seguinte linha:

GRUB_CMDLINE_LINUX=""

Para:

GRUB_CMDLINE_LINUX="rootflags=data=journal"


E depois, executar o comando:

# update-grub

Para deixar o sistema de arquivos ext3/4 em um meio termo, com um bom desempenho e consistência mesmo usando journal interno, seria usado as seguintes opções no "/etc/fstab":

UUID=4ccfc585-1d20-4845-9c00-0d2a44bf8e0a / ext3 errors=remount-ro,barrier=1 0 1

UUID=85eebfa7-88ae-4de8-8125-3cfbce5abe29 /home ext4 errors=continue,rw,barrier=1,commit=40,relatime 0 2


Pois a partição que contém o diretório raiz iria manter o modo de operação padrão, assim como na partição /home, porém, /home teria uma ganho com as opções commit e relatime.

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

Faça o GNU/Linux falar as horas para você

Construindo um portscanner TCP com Python

Instalação de um servidor de mensagens instantâneas Openfire na sua rede com clientes Microsoft Windows e cliente Jabber Exodus

XFree86 - Um pouco da história deste poderoso ambiente gráfico para UNIX

Instalando EpiInfo 6.0.4d no Slackware 10.2

Leitura recomendada

Criando um pacote TXZ no Slackware

Montando Volumes no Docker

Entendendo e configurando o LVM manualmente

Git - Ciclo básico de trabalho

Aprendendo NFS - Network File System

  
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