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

Por: Edson em 31/07/2012


Opções de montagem e vantagens e desvantagens de usar journal externo



Nesta parte do artigo, dedico a esclarecer qual é a finalidade principal de cada opção de montagem que podem ser usadas para tunar os sistemas de arquivos abordados no artigo, podendo incluir as mesmas no "/etc/fstab", além de explicar a vantagem de usar um journal externo.

Opções:
  • atime: Opção usada para atualizar o tempo de acesso aos arquivos, este tipo de informação é armazenada nos inodes dos arquivos. Por exemplo, quando você clica com o botão direito e vai em 'Propriedades' do arquivo, lá tem o tempo de acesso.
  • noatime: Esta opção faz com que o sistema de arquivos não atualize o tempo de acesso aos arquivos. Caso habilite este comportamento no F.S., não conseguirá obter o tempo preciso do último acesso feito aos arquivos gravados.
  • async: Opção usada para que o sistema de arquivos faça as operações de forma assíncrona. A sincronização de dados (input/output) será feita depois, e não na hora da transferência de dados.

    Por exemplo: Se você está gravando dados no seu disco externo, os dados serão sincronizados aos poucos, de forma tardia.

    Caso esqueça de desmontar o dispositivo, removendo o mesmo sem desmontar da forma correta, o risco de perder seus dados é alto, este é o comportamento padrão dos sistemas de arquivos usados no GNU/Linux.

  • sync: Opção usada para que o sistema de arquivos trabalhe de forma síncrona, fazendo a sincronização de dados (input/output) no momento da transferência de dados.

    Por exemplo: Você vai gravar alguns arquivos no pendrive com esta opção habilitada no sistema de arquivos do pendrive, toda a gravação dos dados será feita na hora e não no momento de desmontar o sistema de arquivos.

    Este não é o comportamento padrão dos sistemas de arquivos usados no GNU/Linux. Caso habilite esse comportamento, a transferência de dados ficará bem lenta, principalmente em transferência de dados grandes.

  • diratime: Esta opção é similar ao atime, mas ao invés de atualizar o tempo de acesso aos arquivos, atualiza o tempo de acesso aos diretórios.
  • nodiratime: Ao contrário da opção diratime, está opção não atualiza o tempo de acesso ao diretórios, pode ser usada para ter um pouco mais de desempenho, já que toda ação de acesso não será armazenada nos inodes.
  • dirsync: Similar a opção sync, mas ao invés da sincronização de dados (input/outpu) serem feitas de forma síncrona nos arquivos, serão feitas nos diretórios.
  • relatime: Opção usada para atualizar o tempo de acesso aos arquivos referentes à modificação/alteração nos arquivos.

    Caso habilite este comportamento no seu sistema de arquivos, o tempo de acesso aos arquivos só será atualizado caso o tempo relativo à modificação for mais atual do que o antigo, ou seja, só será atualizado caso haja alguma modificação/alteração nos arquivos, e não um simples acesso. Esta opção é similar ao noatime. Caso deixe a mesma habilitada terá um ganho de desempenho.
  • norelatime: Esta opção desabilita o recurso relatime, pois não vai atualizar nos inodes o tempo de acesso relativo à modificação e/ou alteração.
  • barrier: Este comportamento chama-se barreira, e é usado em conjunto com journal.

    Para entender melhor esta opção de comportamento do sistema de arquivos, temos que ter em mente o seguinte: toda alteração no sistema de arquivos que usa journaling, armazena primeiro os registros de alterações de sua estrutura, seja um arquivo ou diretório, no journal, para posteriormente fazer a gravação efetiva dos dados.

    Porém, se os blocos de dados e/ou registros de alteração de dados que serão feitos de forma efetiva não forem escritos antes no journal, seu sistema e arquivos poderão comprometer as informações armazenadas na sua estrutura.

    Habilitando o barrier, evita-se a gravação desordenada, evitando que os dados fiquem corrompidos no sistema, pois os blocos de dados e/ou os registros são primeiro armazenados no journal para posteriormente, serem gravados efetivamente no sistema.

    Quando este comportamento é habilitado, é garantido que o F.S. tenha sua consistência mantida, mas em compensação, terá uma perda de desempenho. Caso deixe desabilitada, ganhará desempenho, porém, tenha certeza que o mesmo poderá ficar corrompido de forma mais fácil do que quando este comportamento está habilitado, pois nenhum sistema de arquivos é anti falhas, e sim tem uma tolerância à falhas.

    Para habilitar, coloque no "/etc/fstab barrier=1", ou "barrier=flush" (vai depender do F.S. usado). Caso queira deixar desabilitada, coloque no "/etc/fstab barrier=0", ou "barrier=none" (relativo ao F.S. usado).

Vantagens de se usar Journal Externo

Antes de falar sobre as vantagens, primeiro vem a definição de journal, que é uma área reservada para armazenamento de registros/log de ações que serão feitas nos dados, tais como: leitura/alteração e ou gravação de novos dados na estrutura do F.S.

Para uma melhor compreensão, acesse o artigo Sistemas de arquivos para GNU/Linux, página 2.

O Journal do sistema de arquivos é a parte mais acessada do seu disco rígido. Seja para qualquer ação que você faça o Journal é acessado, ou seja, tanto nas operações de leitura como de escrita.

Desta forma, o disco precisa gravar os dados no journal (log) e no sistema de arquivos. Logo, nota-se que o disco tem que fazer dois movimentos: um para gravação no journal e outro no F.S. em si, além de ter um journal com tamanho limitado.

Isto pode influenciar no desempenho, já que o log fica limitado pelo tamanho e também o Seek time é maior.

Seek time é o tempo gasto para movimentar a cabeça do disco para ler e escrever no disco até a trilha/setor desejado.

No entanto, ao colocar o journal (área de log) em outro disco, tem-se um ganho quanto ao seek time, pois o mesmo disco que armazena o sistema, não precisará fazer dois movimentos (um no sistema de arquivos e outro journal).

Com isso, ganha-se velocidade na leitura/escrita de dados, além de poder deixar o Journal com um tamanho maior, permitindo armazenar mais dados (se necessário) de uma vez. Com isso, o ganho de desempenho é garantido.

Mesmo colocando o journal em outra partição do mesmo disco onde está o sistema, tem-se um ganho de desempenho. Não igual se comparado a colocar em outro disco, mas ganha.

Lembre-se que, para cada partição que usará com journal externo, deverá ter uma partição dedicada para armazenar o journal. Se pretende colocar o diretório "/" e "/home" em partições separadas e usar a área de registro para ambas partições com localização externa, então dedique duas partições para para receber o log, cada partição para um diretório.

Desvantagem de usar Journal Externo

Se o disco rígido em que está o journal externo for acidentalmente desligado, você não poderá iniciar o seu sistema, mas nenhum dado estará perdido!

Nem mesmo dando boot pelo LiveCD, você terá acesso aos seus dados. Você precisará do Journal externo para ler os seus dados. Basta então, religar o disco rígido em questão, na mesma ordem em que tudo foi configurado, que tudo volta ao normal.

Se o disco rígido em que está o journal externo chegou ao fim de sua vida útil, ou está com defeitos irreparáveis, você não poderá acessar os seus dados e o que estiver fazendo no momento do problema pode estar perdido.

Aí você pode perguntar-se: Como então eu volto a ter acesso aos meus dados?

Resposta: Substitua o disco onde estava o journal da partição, aplique o sistema de arquivos em uma nova partição, e execute os comandos que serão usados nas páginas seguintes para preparar o HD para receber o journal externo, e anexar o journal do sistema no novo HD. Depois reinicie a máquina e use o sistema.

* NOTA: Nem todos os sistemas de arquivos abordados neste artigo poderão migrar o seu journal externo para outro dispositivo, sem que o dispositivo anterior (dispositivo que continha o journal) esteja presente e/ou sem formatar a partição que contém o sistema.

Independentemente do seu sistema de arquivos e das modificações que você possa fazer no seu sistema, sempre faça backup antes de fazer as alterações instruídas nas páginas seguintes.

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

IPtables - Trabalhando com Módulos

Clonezilla - Gerando e restaurando backups completos (Parte I)

FwLogWatch - Analisando Registros do IPtables

Sistemas de arquivos para GNU/Linux

Ingressar desktop GNU/Linux no domínio Active Directory do Windows Server 2008

Leitura recomendada

Filesystem LVM

Adicionando Novo Disco - RHEL e CentOS

Fazendo particionamento avançado no Debian

Removendo vírus de Windows com LiveCD GNU/Linux

ZFS no GNU/Linux

  
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 eabreu 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 eabreu 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 eabreu 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 eabreu 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 eabreu 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 leoteodoro 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
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts