O que é “tunar” e o que é Sistemas de Arquivos

Antes de começar a tratar sobre o assunto de tunar o sistema de arquivos, precisamos saber o que é um sistema de arquivos.

Um sistema de arquivos é uma estrutura lógica que é utilizada para armazenar e organizar informações no sistema. Caso queira aprofundar seus conhecimentos e saber mais sobre sistema de arquivos, leia o artigo do link abaixo:

• Artigo: Sistemas de arquivos para GNU/Linux

– O que é “tunar” um sistema de arquivos ?

Tunar um sistema de arquivos significa alterar características do mesmo, permitindo que F.S. seja personalizado para fins diversos.

Seja para uma otimização, deixando o sistema de arquivos mais rápido, ou para uma personalização mais cautelosa, permitindo que o mesmo fique mais consistente e robusto, para não corromper os dados caso aconteça algum erro ou falha.

O artigo irá abordar as práticas de tunar os sistema de arquivos mais usados no pelas distribuições GNU/Linux deixando os mesmos mais velozes, leves e/ou mais consistentes.

No final do artigo irei mostrar gráficos que representam um teste de desempenho de cada um após a personalização para melhor desempenho, trata- se de uma benchmark (teste de desempenho) básico para dar uma ideia da velocidade que o mesmo pode obter em determinadas tarefas.

Observações

Nas páginas seguintes, toda a personalização é feita pela linha de comando, então, se você não está seguro em fazer as alterações abordadas nas próximas páginas, ou não gosta de linha de comando, pare por aqui mesmo, caso queira fazer as alterações e/ou fazer uma boa leitura, continue.

Algumas características serão aplicadas antes da instalação da distribuição que será usada, isto será feito com o propósito de obter um melhor funcionamento desde o inicio. Essa é a melhor opção.

Os sistemas de arquivos foram tunados na distro Debian GNU/Linux, versão 6.0.5.

A máquina usada possui um processador Intel® Core™2 Duo, quatro gigabytes de espaço na RAM e um disco SATA 3.0 de 7200 RPMs.

Antes de começar a colocar em prática todo o trabalho, tenha em mãos um LiveCD do Ubuntu, Linux Mint ou Parted Magic, pois será necessário.

Todo o trabalho de “tunar” apresentando nas páginas seguintes foi testado.

Caso sinta-se encorajado a fazer o trabalho, monte seu ambiente de testes para ter certeza de que as alterações serão úteis para uso em produção, para só então, aplicá-las em definitivo.

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 somente serão gravados por completo, no momento que o sistema de arquivos for desmontado.

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

Serão abordadas duas formas de tunar o sistema de arquivos para um melhor desempenho e para torná-lo mais robusto.

Uma das formas que vou utilizar é o journal externo, ou seja, o journal do sistema de arquivos ReiserFS vai estar em outra partição. Porém, você poderá também colocá-lo em uma partição de outro disco.

E a segunda forma vai ser com o journal interno, ou seja, na partição onde está armazenado o sistema.

Para aplicar o journal externo, particione o disco conforme sua necessidade. Contudo, usarei para explicar o seguinte particionamento do disco para instalar o S.O.:

• Partição: /dev/sda1 – Diretório root “/”;
• Partição: /dev/sda5 – Swap;
• Partição: /dev/sda6 – Partição usada para armazenar o journal externo da partição /dev/sda1.

NOTA: Este sistema de particionamento é apenas um exemplo para fins didáticos,não é obrigatório. De forma que, não é preciso usar o journal externo na partição onde ficar root “/”, então, você pode particionar da forma que melhor atende às suas necessidades, adicionando até mais partições se for necessário.

Não vou abordar como particionar usando o fdisk e nem o GParted, pois existem muitos materiais que abordam o uso dessas ferramentas.

Tunando o ReiserFS usando journal externo

Antes de começar a parte prática, tenha em mãos um LiveCD do Ubuntu, Linux Mint e ou Parted Magic, para aplicar as alterações. Caso não tenha no LiveCD (ou no sistema que está usando para particionar e aplicar o sistema de arquivos) suporte a ReiserFS, então instale o pacote “reiserfsprogs”.

Supondo que você já particionou o disco que armazenará o S.O., é hora de aplicar o sistema de arquivos ReiserFS. Mas antes, desmonte as partições que usará no procedimento de aplicação de F.S.

1. Aplique o sistemas de arquivos em “/dev/sda1” com journal externo. O journal da partição “/dev/sda1” ficará no dispositivo “/dev/sda6”, que será a partição raiz e que abrigará toda a estrutura de diretórios.

# mkreiserfs -j /dev/sda6 /dev/sda1

No comando anterior, não especifiquei o tamanho do journal na partição, então, o tamanho assumido por padrão, é 8193 blocos. Caso queira colocar um tamanho de journal acima do tamanho padrão, use junto ao comando mkreiserfs a opção “-s”, ou “–journal-size”.

Sabendo que o tamanho máximo do journal é de 32749 para partições com blocos de 4 kbytes.

Então, com a opção de tamanho ficaria assim:

# mkreiserfs -s 8193 -t 1024 -j /dev/sda6 /dev/sda1

Onde “-s” especifica o tamanho do journal, e “-t” especifica o máximo de blocos que podem ser transferidos para o journal de uma vez. 1024 é o máximo, não consegui fazer com valor superior, e o valor deve ser menor do que metade do tamanho do journal.

Após aplicar o sistema de arquivos, veja como fica a particionamento no GParted na imagem abaixo:

2. Instalação do S.O. Debian GNU/Linux 6.0.5

NOTA: Não tratarei a instalação por completo, apenas partes importantes para finalizar a mesma.

2.1. Na primeira tela de instalação, escolha a opção “Advanced Options” e em seguida “Graphical Expert Install”. Depois carregue os módulos do sistema de arquivos ReiserFS:

2.2. Em particionamento do disco, 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 ReiserFS e adicione o ponto de montagem como root “/”, mas marque para não formatar:

Ao final, o particionamento ficará assim, depois aplique as alterações feitas:

Após a instalação do S.O com journal externo, você terá um sistema ReiserFS com mais velocidade, porém, em um desktop que é usado para acesso à Internet e/ou tarefas básicas, não nota-se diferença a princípio. Ou seja, só repara-se diferença quando está fazendo operações em massa, aí sim notará diferença.

Agora, edite e acrescente algumas opções de montagem para alterar o comportamento do ReiserFS no arquivo “/etc/fstab”:

# vim /etc/fstab

* notail: Por padrão, esta opção já veio ativada após a instalação, mas caso não esteja habilitada, coloque a mesma no fstab. Esta opção muda o comportamento do sistema de arquivos ReiserFS, fazendo com que o mesmo ganhe um pouco de desempenho.

Explicando bem o que esta opção notail faz:

Toda informação que é gravada no disco, é armazenada em blocos de dados, cada bloco possui um espaço para alocar informações que é determinado durante a aplicação do sistema de arquivos.

Desta forma, se um arquivo possuir 17 kbytes de tamanho e for armazenado em um sistema de arquivos cujo tamanho do bloco é 4 kbytes, o arquivo iria ocupar cinco blocos de 4 kbytes. Assim, o último bloco ficaria com 3 kbytes de espaço sobrando sem poder serem usados.

Mas, com o recurso “tail packing”, este espaço restante livre mencionado na explicação anterior, pode ser preenchido com os restos de dados de outros arquivos.

Isto pode causar fragmentação, mas como o sistema de arquivos está com a opção “notail” habilitada, a fragmentação é praticamente nula, e a velocidade de acesso aos dados torna-se rápida, já que os “restos” de dados não serão armazenados em blocos com espaços que estão sobrando. Mas em compensação, haverá perda de espaço.

* data=writeback: Esta opção faz com que o sistema de arquivos ReiserFS atue no modo de operação writeback, gravando no journal apenas os metadados a cada ação nos arquivos, sem forçar a gravação dos metadados no sistema de arquivos após a gravação no journal. Isto garante maior desempenho mas poderá perder dados com maior facilidade.

Uma outra forma de melhorar ainda mais o desempenho, porém perdendo algumas informações (como data de acesso a arquivos e diretórios), seria adicionar no “/etc/fstab”:

As outras opções já foram abordadas na página anterior.

Lembre-se que, adicionando a opção de montagem ‘data=writeback’, o risco de perder dados é maior, porém, como o journal está externo já existe um ganho de desempenho.

Podemos adicionar, ou retirar, algumas opções para mudar o comportamento do sistema de arquivos, fazendo o mesmo ficar mais consistente e/ou continuar rápido, mas mantendo um bom nível de consistência.

Vejam só como ficaria as opções de montagem no “/etc/fstab”, deixando o sistema de arquivo num misto de consistência e velocidade com journal externo:

Ou, deixa manter os dados com o máximo de segurança sem importar-se com a velocidade. Veja o exemplo abaixo adicionado no “/etc/fstab”:

Após aplicar as alterações, notará que vai ficar lento, principalmente em atividades de gravação e transferência de dados.

É importante deixar bem claro que, caso o dispositivo que contém o journal externo do F.S. do sistema chegue ao fim de sua vida útil, ou seja danificado. O seu sistema não poderá mais ser acessado enquanto não houver um novo journal externo.

Para resolver isso, execute os comandos a seguir com o sistema de arquivo do sistema desmontado:

# reiserfstune -f –no-journal-available –journal-new-device /dev/sdb2 /dev/sda1

No comando acima, estou supondo que o novo dispositivo que conterá o journal do sistema é “/dev/sdb2”, e o dispositivo que contém o sistema é “/dev/sda1”.

As opções:

• journal-new-device: indica a nova localização do journal do F.S. do sistema.
• no-journal-available: indica que o dispositivo “/dev/sda1”, ou seja, o dispositivo que contém o sistema, não tem journal.

Você pode ainda mudar o tamanho do journal com a opção “-s”, junto ao comando reiserfstune.

Mas tenha em mente que foi criado um novo journal e conteúdo, do antigo foi perdido, de maneira que se antigo log contém alguma informação para ser recuperada, a mesma foi perdida com a criação do novo journal.

Tunando o ReiserFS usando journal interno

Para tunar o sistema de arquivos com journal interno, o procedimento é mais fácil, pois não precisa fazer alterações especificas antes e durante a instalação do S.O., basta apenas manipular as informações dentro o “/etc/fstab”, pois assim é mais fácil.

As opções de montagem já usadas anteriormente podem ser usadas também com journal interno. E estarei usando o mesmo esquema de particionamento já visto com journal externo.

Por exemplo, para um maior desempenho mesmo com o journal interno, poderíamos fazer o ReiserFS trabalhar bem rápido, adicionando as seguintes opções no “/etc/fstab”:

Ou, deixar o ReiserFS com mais ganho de desempenho, adicionando as seguintes linhas no “/etc/fstab”:

Ou, tunar o ReiserFS deixando-o mais robusto, porém perdendo velocidade, para manter os dados de sua estrutura:

Lembre-se que todas estas personalizações tem que ser utilizadas para bons resultados junto às características positivas do ReiserFS.

Exemplo: O ReiserFS trabalha melhor com arquivos pequenos.

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 do sistema de arquivos (inodes, diretórios), 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

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:

* 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:

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

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

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:

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:

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:

Para tunar o JFS, usarei o esquema de particionamento descrito abaixo. Porém, assim como nos outros sistemas de arquivos, farei uso do journal externo e interno para fazer este trabalho.

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/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.

Tunando usando o journal externo

Diferente do que foi feito anteriormente, vou mostrar duas formas de deixar o sistema instalado com journal externo. Primeiro, vou mostrar como fazer antes da instalação do sistema.

Para isso, dê boot pelo LiveCD, como o Parted Magic ou outro, e execute os comandos a seguir. Se no sistema que está usando para executar as tarefas não estiver instalado os comandos, será necessário instalar o pacote “jfsutils”.

1. Prepare as partições que armazenarão os logs com os comandos abaixo, desta forma, estamos dizendo que as partições “/dev/sdb1” e “/dev/sdb2”, são partições de journal externo:

# jfs_mkfs -J journal_dev /dev/sdb1
# jfs_mkfs -J journal_dev /dev/sdb2

2. Em seguida, aplique o sistema de arquivos JFS nas partições onde será armazenado o sistema, indicando que os dispositivos que contém os journals externos são “/dev/sdb1” e “/dev/sdb2”.

# jfs_mkfs -J device=/dev/sdb1 /dev/sda1
# jfs_mkfs -J device=/dev/sdb2 /dev/sda2

Veja como ficaram as partições que receberam o journal:

3. Na instalação do S.O., apenas abordarei as partes importantes que merecem ser destacadas.

3.1. Escolha a opção na tela de boot “Advanced Options” e em seguida “Graphical Expert Install”

3.2. No particionamento, escolha a opção “Manual” para fazer as alterações, e em seguida, escolha as partições onde irá instalar o sistema. Coloque o ponto de montagem para “/dev/sda1” e “/dev/sda2” e escolha o sistema de arquivos JFS com journaling.

Mas, não marque para formatar a mesma, como mostram as imagens a seguir:

3.3. Veja como ficou o particionamento ao final das alterações:

4. Agora, apresento a segunda forma de deixar as partições do sistema com journal externo. Primeiro, certifique-se de que as partições que usarão journal externo estejam desmontadas.

Logue usando um LiveCD, ou usando outro sistema GNU/Linux que tenha instalado no mesmo disco, ou em disco diferente, e execute os seguintes comandos:

# jfs_mkfs -J journal_dev /dev/sdb1
# jfs_mkfs -J journal_dev /dev/sdb2

Estes comandos acima preparam os dispositivos “/dev/sdb1” e “/dev/sdb2” para armazenar o journal. E em seguida, use o comando jfs_tune para dizer ao sistema de arquivos JFS, que o log está anexado em uma partição diferente do sistema:

# jfs_tune -J device=/dev/sdb1 /dev/sda1
# jfs_tune -J device=/dev/sdb2 /dev/sda2

Agora, edite e acrescente algumas opções no “/etc/fstab” para deixar o JFS com melhor desempenho. Veja que o UUID usado, é da partição que foi formatada para ambos. Mude o campo do UUID de sua partição, pois com certeza é diferente do atual:

Porém, se quer ganhar mais desempenho ainda, sem importar-se com as atualizações de tempo de acesso nos diretórios e arquivos, coloque as seguintes opções no fstab:

* NOTA: É muito importante deixar esclarecido que se o dispositivo que contém o journal externo chegar ao fim de sua vida útil, os dados que estão contidos no sistema não poderão mais ser acessados, ou montados, para escrita (somente para leitura) mesmo usando usando Live CD ou de outro sistema presente na mesma máquina.

Mas não fique desesperado caso isso aconteça, pois poderá instalar um novo disco e criar uma nova partição que conterá o journal do F.S. do sistema, fazendo com que o sistema seja acessível novamente com journal na partição do novo disco.

Para isso, execute os seguintes comandos a partir de outro sistema na mesma máquina, ou de um LiveCD:

# jfs_mkfs -J journal_dev /dev/sdb1
# jfs_tune -J device=/dev/sdb1 /dev/sda1

No comando acima, estou supondo que o novo dispositivo que irá conter o journal é “/dev/sdb1”, e que o sistema está no “/dev/sda1”. Depois de executar os comandos, é só reiniciar a máquina e voltar a usar seu sistema.

Mas tenha em mente, que foi criado um novo journal e que o conteúdo do antigo foi perdido, de maneira que se o antigo log contém alguma informação para ser recuperada, a mesma foi perdida.

Tunando usando journal interno

Mesmo com journal interno, podemos deixar o JFS com melhor desempenho, e para isso, farei uso do mesmo esquema de particionamento usado anteriormente.

Agora, vamos adicionar algumas opções ao “/etc/fstab” para deixar o JFS com uma melhor performance ainda:

Observe que são as mesmas opções usadas com o journal externo. Mas mesmo o journal estando interno, as opções noatime e nodiratime já trazem um benefício no desempenho, pois os metadados não armazenarão informações referentes a acessos em arquivos e/ou diretórios. Senão, vai armazenar estas informações, e com certeza não irá gravar as mesmas no journal.

Lembre-se que não é o forte do JFS ter transferências de dados de alta velocidade, principalmente quando for de tamanho pequeno.

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 1024 blocos equivale a 1 Megabyte. No comando anterior especifiquei 105500, então o tamanho do log é 103 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

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

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

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

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.

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:

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:

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

* 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

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:

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

GRUB_CMDLINE_LINUX=””

Para:

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”:

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.

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.

O Sistema de arquivos com journal externo pode ganhar muito desempenho, mas lembre-se de que, se o dispositivo que armazena o journal não puder mais ser acessado, seja por qualquer motivo, o S.O. não poderá mais ser usado. Para acessá-lo novamente, é necessário criar um novo journal para o sistema de arquivos que contém o S.O.

No benchmark realizado e mostrado na página anterior, foram feitos vários testes, porém, para poder avaliar e validar a verdadeira vantagem de tunar um sistema de arquivos, nada melhor do que você mesmo testar e ver se as alterações vão atender às suas necessidades.

Veja também que algumas alterações abordadas no decorrer do artigo podem deixar o F.S. vulnerável, podendo deixar você na mão. Então, antes de aplicar tais alterações na máquina que está em produção, ou mesmo não aplicando-as, faça BACKUP.

Recomendações de uso

Para desktop que usa o diretório /home em partição separada da raiz e possui muitos arquivos pequenos. Use no diretório raiz o sistema de arquivos ReiserFS, e na /home, use ext4 ou próprio ReiserFS.

Caso tenha em um diretório vários arquivos grandes, use XFS com journal interno, como foi abordado no artigo. Pois o XFS tem um bom desempenho com arquivos grandes. Não use XFS com o journal externo, pois apesar de possível seu uso saiba do risco que corre, caso a partição que contém o journal ficar danificada, o seu sistema ficará inacessível.

E, para criar um novo journal externo para poder ter acesso outra vez aos seus dados, só aplicando outra vez o sistema de arquivos XFS na partição que contém o sistema.

Mas, se tem arquivos grandes em uma partição e deseja usar journal externo, use o sistema de arquivos JFS, pois o mesmo trabalha bem com arquivos grandes e tem um bom desempenho com log externo.

No caso de um servidor de rede que não armazena arquivos tão importantes, como DHCP e/ou proxy, deixe o diretório raiz com o sistema de arquivos ext4 ou ext3.