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.137 ]

Por: Edson em 31/07/2012


Tunando o sistema de arquivos XFS



Antes de tunar o XFS, tenha em mente que ele foi desenvolvido para ser usado em sistemas grandes e uma de suas características positivas é trabalhar muito bem com arquivos grandes. Sendo que uma característica negativa, é não ter um bom desempenho com arquivos pequenos.

Também é necessário explicar como sua estrutura está organizada para um melhor entendimento. O XFS é dividido em três partes, cada parte fica localizada uma seção.

As seções são:
  • A seção de dados: Contém todos os metadados (inodes) do sistema de arquivos, bem como os dados do usuário, como arquivos e até mesmo o aquivo de log, caso o journal seja interno. A seção de dados é dividido em um número de grupos de alocação.

    O número e tamanho dos grupos de alocação são determinados pelo comando mkfs.xfs. O número de grupos de alocação controla a quantidade de dados que podem ser transferidos paralelamente.

    Se não tiver uma máquina "potente" (com uma boa quantidade de memória disponível e processador com poder de processamento bom) o número de grupos de alocação não deve ser muito alto, pois isto pode causar sobrecarga no processador. Caso contrário, aumente este número pois pode aumentar o desempenho.

  • A seção de log: É usada para armazenar as alterações de metadados do sistema de arquivos enquanto o mesmo está sendo executado, até que as alterações sejam feitas pela a seção de dados.

    Este é escrito sequencialmente durante as operações normais (enquanto o sistema está em uso) e lido apenas durante a montagem. Ao montar um sistema de arquivos, depois de um acidente, o log é lido para operações completas que estavam em curso no momento do acidente, e restaura a estrutura até onde é possível.

  • A seção de tempo real: É usada para armazenar os dados do sistema de arquivos em tempo real. Antes que qualquer dado seja escrito definitivamente no F.S.

Assim como nos outros sistema de arquivos, vou apresentar duas formas de tunar: uma para desempenho e outra para maior consistência, tanto usando journal externo quanto journal interno.

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

NOTA: Este é apenas um exemplo de particionamento para explicar como fazer o trabalho, ou seja, apenas para fins didáticos. O leitor pode tanto seguir este esquema como pode personalizar da forma que quiser.

Preferi usar este particionamento, pois diretórios como "/home", e outros que podem ser criados, podem armazenar uma grande quantidade de arquivos grandes, e XFS tem um bom desempenho com arquivos grandes.

É importante deixar bem claro também que, o sistema de arquivos XFS quando usa journal externo não tem outra forma de migrar seu journal de uma partição de um dispositivo para outra partição sem perda de dados.

Para fazer tal migração, é necessário aplicar o F.S. na partição onde está instalado o sistema que foi configurado para deixar o journal em outro dispositivo. Pelo menos, não encontrei nenhuma forma que não seja usando o comando mkfs.xfs apresentado no decorrer desta página.

Isto quer dizer que, caso o dispositivo que contém o journal fique defeituoso, ou chegue ao fim de sua vida útil, não terá como acessar os dados do sistema que tem o XFS usando journal externo, nem usando um LiveCD.

A única forma é criar um novo journal usando o comando mkfs.xfs, porém, este comando irá aplicar um novo sistema de arquivos ao sistema que não tem mais journal apagando toda informação contida nele.

Então, se quer usar seu sistema usando o F.S. XFS, a melhor opção é com journal interno, mas caso deseja usar o sistema com XFS e journal externo, é melhor fazer backup de seus dados.

Tunando o XFS usando journal externo

Não será abordado como particionar e nem a instalação passo a passo, apenas detalhes importantes. Mas o esquema de particionamento usado será o mesmo especificado acima. Então, vamos à prática:

1. Instalação do S.O. GNU/Linux Debian 6.0.5. Na primeira tela de instalação, escolha a opção "Advanced options" e em seguida "Graphical Expert Install":
2. Depois, prossiga com a instalação normalmente e particione. Veja como ficou o particionamento usado no artigo:
3. Após instalar o sistema, o GRUB ou LILO, é hora de fazer as partes mais importantes que merecem atenção total.

* NÃO finalize a instalação e escolha a opção de "Executar um shell" para entrar na linha de comando:
3.1. Na linha de comando, veja que o dispositivo que estou usando no artigo e que armazena "/home" é "/dev/sda2", então, desmonte o mesmo. Caso use outro, troque conforme sua necessidade:

# mount
# umount /dev/sda2
3.2. Agora vamos aplicar o sistema de arquivos XFS com Journal externo armazenado na partição "/dev/sdb2":

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



Opções:
  • -f : Quando está opção é usada, indica que já existe um sistema de arquivos XFS no dispositivo que irá ser formatado, o F.S. existente será sobrescrito.
  • -l : Seção de opções de log. Estas opções especificam a localização, tamanho e outros parâmetros da seção de log do sistema de arquivos.

    Existem vários parâmetros nesta seção, mas explicarei os usados:
    • logdev : Este parâmetro indica o dispositivo que armazenará o log. Ele é usado quando se deseja usar o journal externo em outra partição do mesmo disco ou de outro disco. No comando anterior, armazenei o journal no dispositivo "/dev/sdb2".
    • size : Parâmetro usado para especificar o tamanho do log. No comando anterior, usei um gigabyte de tamanho para o journal (o mínimo é 512 blocos).
  • -d : Seção de opções de dados. Estas opções especificam a localização, tamanho e outros parâmetros da seção de dados do sistema de arquivos.

    O parâmetro usado nesta seção foi:
    • agcount : Este parâmetro especifica o número de grupos de alocação. Como já foi explicado anteriormente, o XFS divide o a sua estrutura lógica de arquivos em grupos de alocação para aumentar o desempenho com leituras em paralelo dos blocos e inodes.

      Mas cuidado ao escolher o número de grupos de alocação usados, pois colocando um número muito alto e/ou baixo demais poderá perder desempenho de acordo com a carga do sistema e do desempenho da máquina.

      O comando mkfs.xfs calcula o número de 'agcount' de acordo com o tamanho do dispositivo a ser formatado. Seus valores variam normalmente entre 4, 8, 16 e 32. Você também pode colocar outros valores como 2, 6 e 56, ou até mesmo números maiores.

      Recomendo testar em uma máquina separada, para depois ser colocado em produção a melhor configuração que atendeu às necessidades. Na formatação usada no artigo usei o valor de "4", mas usei o mesmo pois o espaço da partição em disco é pequeno.
  • -i : Parâmetro usado para especificar opções de inodes. Esta opção especifica o tamanho do inode do sistema de arquivos, e outros parâmetros de alocação de inode.
    • maxpct : Este parâmetro especifica a porcentagem máxima que o sistema de arquivos pode alocar com inodes. Os valores padrões são: 25% para um sistema de arquivos com menos de 1TB, 5% para os menores que 50TB, e 1% para os acima dos 50TB.

      Estes parâmetros influenciam no espaço em disco, podendo fazer você desperdiçar espaço em disco. Com isso, vocês podem notar que o XFS foi pensado para ser grande.

3.3. Adicione o novo "UUID" da partição "/dev/sda2" que armazena o home dos usuários do sistema instalado no final do arquivo "/target/etc/fstab". Este arquivo é o "/etc/fstab" do Debian instalado.

E em seguida, edite o fstab com as opções de montagem a seguir, trocando o "UUID" correspondente à partição Home pelo que foi enviado para o fim do arquivo.

* NOTA: Troque o "UUID" informado pelo "UUID" da partição do disco usado.

# blkid /dev/sdb2 >> /target/etc/fstab
# nano /target/etc/fstab


UUID=68f06b5-1e92-4348-9a7f- 77c47801f6b     /home    xfs    rw,logdev=/dev/sdb2,relatime,allocsi ze=64m   0   2


Depois de aplicar as alterações, salve-as.

As principais opções adicionadas ao fstab do sistema recém instalado:
  • logdev : Informa aonde se encontra o journal externo. Se esta opção não for especificada no fstab, o sistema de arquivos ficará impossibilitado de ser montado.
  • allocsize: Este parâmetro especifica o tamanho final da pré alocação do Buffer de I/O. Seu tamanho varia de 64Kib a 1Gib.

    Esta opção ajuda a diminuir a fragmentação do disco e aumenta a velocidade de transferência de arquivos grandes. Se está usando o sistema de arquivos apenas para armazenar arquivos grandes, use 512 MB ou mais.

    Na prática, quanto maior esse número, melhor a taxa de transferência, mas o sistema pode ficar mais preso à processos ao transferir muitos dados.

3.4. Monte a partição novamente e volte para a tela de opções, finalize a instalação escolhendo a opção: Finalizar a Instalação

# mount -t xfs /dev/sda2 /target/home -o logdev=/dev/sdb2,rw
# exit
Depois da instalação do S.O e iniciar o mesmo, ainda pode acrescentar alguns comportamentos para melhorar o desempenho:

UUID=68f06b5-1e92-4348-9a7f-77c47801f6b /home xfs rw,logdev=/dev/sdb2,relatime,allocsize=64m,delaylog,logbsize=128    0    2


* Note que, com algumas dessas opções, poderá perder dados em caso de erros que aconteçam no sistema.
  • delaylog : Este parâmetro atrasa a gravação das informações no journal do XFS o máximo possível. O delaylog acelera muito o XFS, mas aumenta o risco de perda de dados no caso de uma queda de energia ou travamento do sistema.

    O journal não está sendo desativado, apenas a gravação está sendo atrasada. Esta opção pode não funcionar em versões antigas do kernel ou do XFS, por isso, tenha um kernel sempre atual para usar esta opção junto com XFS, como o kernel 2.6.x ou 3.x.

  • logbsize : Parâmetro que especifica o tamanho de cada buffer na memória, podendo ser especificado em Bytes ou Kilobytes, sendo que o padrão é 32k nas versões mais recentes do kernel.

    Podendo aumentar este valor para 64k, 128k até o máximo de 256k. O logbsize pode ajudar muito o XFS a lidar com arquivos pequenos e aumenta o consumo de RAM. Usei o valor de 128 mas caso tenha um sistema maior use 256.

Mas, se mesmo assim você não está satisfeito e quer mais velocidade sem se importar com perda de dados, faça:

UUID=68f06b5-1e92-4348-9a7f-77c47801f6b /home xfs
rw,logdev=/dev/sdb2,norelatime,allocsize=64m,delaylog,logbsize=128,noatime,nodiratime,nobarrier    0    ; 2


Caso queira mais segurança, para seus dados sacrificando um pouco do desempenho, poderá usar em seu fstab as opções abaixo:

UUID=68f06b5-1e92-4348-9a7f-77c47801f6b /home xfs rw,logdev=/dev/sdb2,allocsize=64m,logbsize=128   0    2


Ou, se quer sacrificar mesmo o desempenho e manter seus dados com menor risco possível de perda de informações, use:

UUID=68f06b5-1e92-4348-9a7f-77c47801f6b /home xfs rw,logdev=/dev/sdb2,allocsize=64m,sync    0    2


Tunando o XFS usando journal interno

Para tunar o XFS com journal interno, utilizarei o seguinte esquema de particionamento:
  • Partição: /dev/sda1 - Diretório root "/";
  • Partição: /dev/sda2 - Diretório home "/home";
  • Partição: /dev/sda5 - Swap.

Seguindo o esquema de particionamento apresentando, execute os seguintes comandos para deixar ambas as partições com um tamanho maior do journal interno:

# mkfs.xfs -f -l internal,size=128m -d agcount=4 -i maxpct=5 /dev/sda1
# mkfs.xfs -f -l internal,size=128m -d agcount=4 -i maxpct=5 /dev/sda2
Veja como ficou o particionamento após aplicação dos comandos:
As opções usadas já foram abordadas antes, porém tenho que informar que o log ficou na mesma partição do diretório "/home" do sistema.

Lembre-se que o "-l" indica a seção de log. Onde o journal está localizado e o tamanho do mesmo, além de outras informações.
  • internal: Indica que o journal é interno. Enquanto que a opção "size" informa o tamanho do mesmo. Usei 128 megabytes pois não posso exagerar quando o journal está localizado na mesmo volume, pois ocupará muito espaço, podendo deixar o sistema muito lento. Não darei explicações das outras opções usadas, pois as mesmas já foram explicadas anteriormente.

Em seguida, instale o sistema operacional. Como explicado desde o início, estou usando o Debian 6.0.5 para aplicar as alterações.

1. Na primeira tela de instalação, escolha a opção "Advanced options" e em seguida, "Graphical Expert Install"
2. Como não mostrarei detalhes da instalação, o próximo passo é o particionamento do sistema. Então, prossiga com a instalação até chegar ao particionamento.

Escolha a opção "Manual" e deixe a partição raiz conforme mostrado na imagem abaixo, ou seja, deixe marcado para usar o sistema de arquivos XFS em ambas as partições, e adicione o ponto de montagem para root "/" e home "/home", mas marque para não formatar:
Particionamento de '/dev/sda1", partição com diretório root "/":
Particionamento de "/dev/sda2", partição com diretório home "/home":
Veja na imagem abaixo, como ficou o particionamento final:
Conclua a instalação e em seguida, inclua as seguintes alterações no arquivo "/etc/fstab" do sistema:

UUID=72fe0d80-ee18-4e8f-84da-8e5700d38c66 /     xfs rw,relatime,attr2,delaylog,nobarrier,logbsize=256    0    1

UUID=df045744-39ef-491c-85f6-13082112dce7 /home xfs rw,relatime,attr2,delaylog,nobarrier,logbsize=256    0    2


Usando estas opções, o XFS terá um bom desempenho, já que o tamanho do journal, mesmo localizado internamente é grande. Mas existe risco de perda de dados. Mas, se não importa-se com isso e quer mais desempenho, coloque no seu fstab as seguintes opções:

UUID=72fe0d80-ee18-4e8f-84da-8e5700d38c66 /     xfs rw,norelatime,allocsize=64m,delaylog,logbsize=128,noatime,nodiratime,nobarrier  0  1

UUID=df045744-39ef-491c-85f6-13082112dce7 /home xfs rw,norelatime,allocsize=64m,delaylog,logbsize=128,noatime,nodiratime,nobarrier  0  2


Desta forma, o desempenho irá aumentar, mas o risco de perda de dados também aumentará.

Veja que de acordo com as opções usadas, o XFS irá mudar seu comportamento padrão e não irá atualizar nos inodes a data do último acesso em arquivos e diretórios, assim como atrasar a gravação dos dados no journal.

Veja uma forma de colocar um meio termo, entre segurança dos dados e desempenho:

UUID=72fe0d80-ee18-4e8f-84da-8e5700d38c66 /     xfs rw,allocsize=64m,logbsize=128  0  1

UUID=df045744-39ef-491c-85f6-13082112dce7 /home xfs rw,allocsize=64m,logbsize=128  0  2


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

Multiboot pelo pendrive usando grub2: instalando várias distros a partir de uma unidade de armazenamento móvel

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

Compilando Kernel no CentOS 6.0

VPN - usando SSH

Apresentando o Btrfs - Nova geração de sistema de arquivos para GNU/Linux

Leitura recomendada

Backup fácil de seus arquivos com o Backintime

Explorando NFS mal configurado

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

GmailFS - sua conta de e-mail como um sistema de arquivos no Slackware 10.2

Arquivos duplicados? fdupes neles!

  
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