jun 292019
 

Se você usa Linux, alguma vez já notou uma lentidão extrema – a ponto de algumas vezes deixar o sistema irresponsivo – ao copiar arquivos grandes, de alguns gigabytes, para mídias lentas, como pendrives USB (especialmente aqueles “genéricos”, que oferecem baixa performance)? Se o seu computador é 64 bits e tem bastante memória RAM (8 GB ou mais), muito provavelmente já notou isso. Tanto é que até o Linus Torvalds já abordou esse problema [1], há alguns anos atrás; mesmo assim, ainda não há uma solução definitiva, mas existem tunings do subsistema de Virtual Memory do kernel do Linux que minimizam esse problema.

Antes de continuar, é preciso entender um pouco sobre alguns conceitos do gerenciamento de memória do Linux. Não vou entrar em muitos detalhes, pois este não é um artigo acadêmico, mas no final colocarei algumas referências para quem quiser se aprofundar mais. Um primeiro conceito que deve ficar claro é: o Linux trabalha por padrão com buffered I/O. De forma simplificada, isso significa que as operações de escrita simplesmente copiam os dados para a memória RAM [2], e depois, em background, o kernel vai fazendo a escrita em si (flush) no dispositivo destino. Dado isto, entra o segundo conceito: dirty memory, que é justamente essa informação que está temporariamente na memória RAM, esperando ser escrita em um dispositivo de armazenamento.

Continue reading »

jun 192018
 

ESTRUTURA DA TABELA E INSERÇÃO DE REGISTROS

O intuito deste artigo é compartilhar um pouco da minha experiência com migração de arquivos BLOB em um banco de dados Oracle para sistema de arquivos utilizando Python.

Antes de efetivamente partirmos para o código de migração, vamos ver os dados de acesso e como será a estrutura da tabela.

Utilizo os seguintes dados de acesso para o esquema no Oracle:

  • user: desv
  • pass: 123456
  • service name: xe
  • IP do host onde está o SGBD do Oracle: 192.168.1.131

Vamos utilizar a estrutura da tabela a seguir:

CREATE TABLE TB_ARQUIVO (
	COD_ARQUIVO           NUMBER PRIMARY KEY,
	DTHINCLUSAO           DATE NOT NULL,
	ARQUIVO               BLOB,
	DS_ARQUIVO            VARCHAR2(50 BYTE),
	DS_PATH_ARQUIVO       VARCHAR2(255 BYTE)
);

Continue reading »

jan 212017
 

INTRODUÇÃO

 

O título deste artigo é Convertendo Sistemas de Arquivos. No entanto, poderia ser também “Brincando com Sistemas de Arquivos”, pois foi justamente isso que fiquei fazendo após descobrir a existência de um programa chamado fstransform, cuja finalidade é converter um sistema de arquivo em outro sem a necessidade de formatação.

ALERTA

Desde já quero esclarecer que todos os passos realizados aqui foram efetuados em uma máquina virtual e que os arquivos contidos nesse HD Virtual não eram importantes. Apesar que em todos os testes os resultados foram positivos, sem nenhuma perda de dados, eu recomendo fortemente a realização de um backup de todos os arquivos e sistemas envolvidos, caso o leitor deseje efetuar essas conversões também.

Recomendo ainda que, assim como fiz, efetue esses testes primeiro em um ambiente virtualizado para não colocar em risco seus arquivos e sistemas. Não me responsabilizo por qualquer perda de dado que venha a ocorrer com o uso desta ferramenta.

A fonte de onde extraí boa parte das informações referentes a esse artigo, é do link abaixo:

A tradução é livre e acrescentei algumas informações a mais baseadas na minha experiência de uso do programa.

Em meus testes, nenhum arquivo foi perdido, todos eles abriram normalmente. No entanto, reforço novamente: não faça nada sem backup.

No texto original, citado no link acima, o autor informa que somente são possíveis conversões entre os sistemas de arquivos tradicionais do Linux:

  • Ext2
  • Ext3
  • Ext4
  • JFS
  • XFS
  • ReiserFS

De Ext4 para NTFS, por exemplo, ele afirma que não é possível. Mas não foi bem isso que ocorreu nos meus testes.

Continue reading »

Buscando texto dentro de arquivos no Linux

 Clusterweb, ClusterWeb, Leitura Recomendada, Linux, Profissional de TI, Shell Script, Ubuntu  Comentários desativados em Buscando texto dentro de arquivos no Linux
nov 212014
 

Um recurso legal de ter à disposição, principalmente a programadores, é a busca em conteúdo de arquivos. Normalmente temos isto no gerenciador de arquivos, porém se quisermos fazer “na mão”, talvez até gerar uma automação usando ShellScript, uma solução é usar o comando grep.

Sintaxe:

grep -R [string buscada] [diretório base]
* -R define a recursividade da busca, ou seja, a busca irá partir do diretório base e seguir para seus subdiretórios também.
 

Continue reading »

Sistemas de arquivos para GNU/Linux

 Clusterweb, Firewall, Linux, Redes  Comentários desativados em Sistemas de arquivos para GNU/Linux
mar 082013
 
Introdução

Antes de começar a falar sobre os sistemas de arquivos, temos que ter em mente o que é um sistema de arquivos.

Sistema de arquivos é uma estrutura lógica que permite armazenar informações em massa e de forma bem organizada, permitindo que um Sistema Operacional ou aplicações possam ser usadas pelo computador, assim como gravar novas informações, e essas informações possam ser acessadas posteriormente.

Um sistema de arquivos depende de estruturas de dados sobre os arquivos. Uma dessas estruturas são os metadados de dados que descrevem os dados. Cada arquivo está associado com um inode, o qual é identificado por um número inteiro, muitas vezes referido como um número ‘i-‘, ou número de inode.

Inodes armazenam informações sobre arquivos e diretórios (pastas), tais como a propriedade do arquivo, modo de acesso (ler, escrever, executar permissões) e tipo de arquivo. Em muitos tipos de implementações de sistemas de arquivos, o número máximo de inodes é fixado no momento da criação do sistema de arquivos, limitando o número máximo de arquivos que o sistema de arquivos pode conter.

– Posso usar Sistema Operacional, ou alguma aplicação, sem ter que aplicar um sistema de arquivos?

Não, o disco rígido que armazena as informações é formatado fisicamente pelo fabricante, e esse tipo de formatação não faz com que o disco possa armazenar informações, porém, não se consegue utilizar o mesmo, pois ainda precisa de uma estrutura lógica para utilizar todo o espaço que o disco disponibiliza.

Objetivo do artigo

Não faz parte do objetivo do artigo fazer um estudo aprofundado sobre cada sistema de arquivos abordado, mas sim, abordar as características dos mesmos, permitindo conhecer mais de cada um.

Esclarecimentos

Todo e qualquer sistema de arquivos não é ANTI-FALHAS.

O mesmo não impede que sua estrutura de dados fique corrompida ou danificada após um desligamento inesperado causado por falta de energia, ou por travamento no sistema ou aplicação, fazendo com que você seja obrigado a usar o botão de desligamento ou de reinicialização.

E após desligar ou reinicializar desta forma, pode ter certeza que seu HD logo ficará com badblocks, principalmente se este tipo de situação acontecer constantemente. Não se impressione se o seu sistema, após um acontecimento destes, não conseguir mais ser acessado, ou precisar de reparos manuais para poder ser usado novamente.

O único sistema que ouvi falar bem quanto à tolerância de falhas, mas não cheguei a usar e nem a testar, foi o ZFS, desenvolvido pela Sun Microsystems.

Aí você pode se perguntar:

– Mas o que é um ‘badblock’ e por quê o sistema pode ficar corrompido, caso aconteça o que você citou acima?

1° – Um ‘badblock’ é uma área danificada de um disco que não pode ser mais utilizada, pois o dano é permanente.

Este tipo de dano pode ser causado por desligamentos forçados, como por exemplo, apertar o botão de desligamento da máquina, assim como reinicialização forçada, formatações erradas, esbarrões no HD, falta de energia etc.

Quando há muitos ‘badblocks’, seu HD está próximo do fim de sua vida útil, pois o mesmo está com muitos problemas.

2° – O sistema de arquivos pode ficar corrompido e o SO ficar inacessível, porque algum, ou alguns dados que estejam sendo utilizados pelo sistema no momento em que acontece o que foi citado anteriormente ainda não foram salvos, fazendo com que o mesmo fique incompleto, sendo assim corrompido. E se um arquivo deste for importante para o sistema, pode fazer com que o sistema fique inacessível.

Porém, muitos dos sistemas de arquivos tem tolerância de falhas, alguns mais consistentes e robustos que os outros.

Para os sistemas de arquivos usados no GNU/Linux, toda essa consistência tem ajuda do recurso muito utilizado que é o Journaling.

Journaling

Journaling é um recurso usado pelos sistemas de arquivos que consiste em uma área dedicada para registros, armazenando todas as ações que serão feitas nos arquivos, como gravação e/ou alteração de dados, por exemplo. Seja armazenamento somente de metadados, ou de metadados e dados de arquivos, permitindo restaurar o sistema de arquivos, caso aconteça algum erro inesperado.

A principal finalidade do ‘journaling’ é recuperar o sistema de arquivos de erros (tolerância de falhas), sejam eles causados pelo sistema, aplicações ou desligamentos incorretos de forma forçada ou inesperada.

Com isso é possível localizar todas as operações que não haviam sido completadas, restaurando a consistência do sistema de arquivos e permitindo que o sistema operacional continue sendo utilizado.

Aí você ainda fica com dúvida e pergunta: Mas como assim?

Com o ‘jounaling’, o sistema de arquivos passa a registrar em uma área especial chamada journal, ou log, as ações que serão feitas nos arquivos (gravação ou alteração de dados, por exemplo) antes da gravação no FS em si.

Após a execução, as operações registradas no log são tidas como concluídas e, portanto, eliminadas. Note que todo este procedimento acontece de maneira extremamente rápida.

Mas em que exatamente, o ‘journaling’ mostra-se vantajoso?

Os registros de log são escritos antes que as mudanças efetivamente ocorram no sistema de arquivos. Estes registros somente são eliminados quando as mudanças são executadas.

Se, por exemplo, o computador for desligado repentinamente (como ocorre em falta de energia elétrica), o sistema de arquivos verificará os registros existentes no ‘journal’ e executará aquilo que estiver marcado como não realizado. Isso faz com que o risco de perda de dados diminua drasticamente, já que o sistema operacional saberá ‘onde parou’.

Porém temos que ter em mente que este recurso não é anti-falhas e sim, um recurso para tolerar falhas até um certo ponto. Pois esta tolerância não previne 100% de erros como os citados anteriormente, toda essa tolerância a falhas pode acabar de uma hora para outra, após várias quedas de energia ou desligamentos forçados.

Contudo, nem todos os sistemas de arquivos que usam o ‘journaling’ possuem uma boa implementação do mesmo, fazendo com que este recurso não seja 100% confiável.

Se você começar a desligar o sistema incorretamente com frequência, vai perceber que, algumas vezes, o sistema não será capaz de verificar o ‘journal’, e o sistema de arquivos terá que ser verificado usando um utilitário para verificação da integridade do sistema de arquivos, tentando localizar todas as operações que não haviam sido completadas para tentar recuperar a integridade de alguns arquivos, fazendo com que, quase sempre, alguns arquivos sejam perdidos.

Técnicas de journaling

  • Journal Físico: Consiste em registrar uma cópia antecipada de todos os blocos de arquivos que serão posteriormente gravados no sistema de arquivo principal. Se houver uma falha quando o sistema de arquivos está gravando, a gravação pode simplesmente ser repetida até a conclusão, quando o sistema de arquivo for montado da próxima vez.

    Se houver uma falha quando a gravação está sendo registrado no journal, a gravação parcial terá um checksum ausente, ou incompatível, e pode ser ignorada na próxima montagem do sistema de arquivos.

  • Journal Lógico: Consiste em gravar apenas os metadados que sofrerão ações, tais como leitura/gravação e alteração dos arquivos. Um sistema de arquivos, com uma ‘journal’ lógico, ainda recupera-se rapidamente após um acidente, mas pode permitir que os dados não sejam recuperados devido a não gravação antecipada dos blocos do arquivo alterado ou em uso, causando corrupção de dados. Porém, isso aumenta o desempenho, nota-se mais isso na inicialização do sistema.

Outras informações

Os sistemas de arquivos para GNU/Linux: JFS, XFS, ReiserFS, ext3 e ext4, possuem ‘journaling’.

O arquivo de log do ‘journaling’ pode estar no mesmo sistema de arquivos, ou em um sistema de arquivos de outra partição, e/ou outro disco. E seu tamanho pode ser aumentado também para melhorar o desempenho.

Então o ‘journaling’ torna-se indispensável para os sistema de arquivos usados hoje e no futuro, pois é através deste recurso que temos uma certa tolerância a certos acontecimentos não planejados.

Sistema de arquivos ext3

O sistema de arquivos ext3 já está entre a comunidade GNU/Linux a muito tempo e ainda é bastante utilizado. O ext3 é uma atualização do sistema de arquivos ext2.

Em relação ao ext2, a principal diferença é a implementação do journaling, um recurso muito interessante abordado na segunda página deste artigo, que consiste no armazenamento de registros para posterior restauração das informações, caso aconteça algum erro.

Principais vantagens

1. Possui journaling. Há três níveis de operação do journaling disponíveis na implementação do ext3:

  • Modo de Operação Ordered (default): O journal é atualizado no final de cada operação. Isto faz com que exista uma pequena perda de desempenho, já que os dados são gravados duas vezes, uma no arquivo que foi alterado ou gravado, por exemplo, e outra no journal. O conteúdo dos blocos de cada dado não é armazenado no journal, porém, os metadados de cada arquivo são armazenados no journal antes dos dados serem escritos no disco, assim como marcação de alteração dos metadados dos arquivos.
  • Modo de Operação Writeback: O journal armazena apenas informações referentes à estrutura do sistema de arquivos (metadata) e não em relação aos arquivos propriamente ditos, e é gravado de forma mais ocasional, aproveitando os momentos de inatividade.

    Este modo é o mais rápido, mas em compensação oferece uma segurança muito menor contra perda e corrompimento de arquivos causados pelos desligamentos incorretos.

  • Modo de Operação Journal: Que é o mais seguro, porém, mais lento. Nele, o journal armazena não apenas informações sobre as ações sofridas, mas também uma cópia de segurança de todos os arquivos modificados, que ainda não foram gravados no disco. A cada alteração, o sistema grava uma cópia do arquivo (no journal), atualiza as informações referentes à estrutura do sistema de arquivos, grava o arquivo e atualiza novamente o journal, marcando a operação como concluída. Como disse, isso garante uma segurança muito grande contra perda de dados, mas em compensação, reduz o desempenho drasticamente. Justamente por causa disso, este é o modo menos usado.

O modo de operação padrão é o Ordered, porém não significa dizer que você não consiga mudar isso. Para usar o modo Writeback ou o modo journal, você deve adicionar a opção “data=writeback” ou “data=journal” nas opções referentes à partição, dentro do arquivo /etc/fstab ou usando o comando tune2fs.

2. Possui indexação de maior quantidade de diretórios;

3. Suporte para tamanhos maiores de volumes e arquivos em relação a sua versão anterior.

Veja abaixo uma tabela:

Tamanho do bloco   Tamanho máx. arquivo   Tamanho máx. fs
1 KiB                            16 GiB             2 TiB
2 KiB                           256 GiB             8 TiB
4 KiB                             2 TiB            16 TiB
8 KiB                            2 TiBsp           32 TiB

4. O ext3 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como:

  • tune2fs
  • mke2fs
  • debugfs
  • e2fsck

Principais desvantagens

  • Funcionalidade: Como o ext3 visa uma grande compatibilidade com o ext2, muitas das estruturas on-disk são similares àquelas do ext2. Por causa disso o ext3 não possui muitas das funções mais recentes, como alocação dinâmica de inodes e tamanhos de blocos variáveis (fragmentos ou caudas).

    Os sistemas de arquivos ext3 não podem ser checados enquanto são montados para escrita. Um dump do sistema de arquivos feito enquanto ele está sendo montado para leitura e escrita pode resultar em dados corrompidos dentro do arquivo de dump.

  • Desfragmentação: Apesar de não fragmentar muito o disco na estrutura do ext3, não há uma ferramenta para desfragmentação online funcional em nível de sistema de arquivos.
  • Recuperação de dados deletados: Diferentemente do ext2, o ext3 zera os ponteiros de blocos nos inodes de arquivos apagados. Ele faz isso para simplificar o acesso de leitura e escrita quando o journal está sendo utilizado após uma montagem.

    Isso, no entanto, previne efetivamente que os arquivos sejam recuperados. Isso provê uma remoção de arquivos um pouco mais segura que em sistemas ext2, o que pode ser tanto uma vantagem quanto uma desvantagem.

  • Verificação do sistema de arquivos: O ext3 é considerado lento na verificação do sistema de arquivos.
  • Criação do sistema de arquivos: O ext3 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.

O sistema de arquivos ext3, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportar o journal, e sim, foi integrado a partir da versão 3 do mesmo, por isso, o journal não é tão eficaz no ext3.

E quando o journal falha, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.

Para muitos, este sistema de arquivos é obsoleto e para outros estável, e tem um bom desempenho.

Sistema de arquivos ext4

O sistema de arquivos ext4 é última versão do sistema de arquivos extFS até o momento, ele é na verdade a atualização do ext3, já abordado no artigo.

O ext4 trouxe, de acordo com seus desenvolvedores, alguns recursos que não existiam no ext3, mantendo alguns que a versão anterior já possuía. Na verdade são recursos que estavam tentando implantar na versão 3 do extFS (ext3), porém, devido a alguns problemas na implementação, lançaram essa nova versão com as características descritas abaixo.

Principais vantagens

  • Possui journaling com aprimoramento de checksum.
  • Melhorias no journaling: Checagem no journaling, checksum aprimorado permitindo ao ext4 ter mais tolerância à falhas que o ext3 e restruturação mais rápida;
  • Suporte para tamanhos maiores de volumes e arquivos em relação à versão 3. O ext4 tem uma margem de 1024 PB (Petabytes) ou 1EB (Exabyte) para partições e 16 TB por arquivo. Isto pode não ser importante para desktops ou servidores simples, porém com certeza é útil para servidores grandes, configurados em Raid e de alta disponibilidade.
  • A indexação de quantidade de diretórios foi aumentada;
  • Suporte a recuperação de arquivos Undelete: Suporte à recuperação de arquivos, permitindo que arquivos seja recuperados.
  • Checagem rápida do sistema de arquivos: O fsck está mais rápido por que a nova estrutura de organização de blocos permite que partes não usadas do HD sejam puladas, o que economiza tempo numa eventual checagem.
  • Desfragmentação online: ext3 deixava os arquivos com um pouquinho, mas bem pouquinho de fragmentação. Agora não deixa mais. O ext4 vai desfragmentando enquanto os arquivos vão sendo alocados.
  • Melhorias na pré-alocação: Às vezes um programa vai usar um espaço do HD mas não na hora, então ele reserva o espaço que vai usar, fazendo uma pré-alocação, ou seja, ele guarda aquele espaço pra ele e ninguém mais pode usar, como se fosse uma reserva. Para essa ação, a maioria dos file systems enchem de zeros os inodes que eles vão reservar.

    Quando essa ação é executada milhares de vezes, como em um banco de dados, esse tempo de escritas de zeros geram um delay de tempo desnecessário. O ext4 vai permitir pré-alocação de arquivos sem fazer isso, o que vai garantir uma melhoria na performance, principalmente nas rotinas de bancos de dados e em ferramentas multimídia.

  • Tempo de alocação estendido: O ext4 vai conseguir manter a alocação do espaço em disco até o último momento, o que pode trazer mais performance.
  • Maior número de subdiretórios: O ext3 colocava um limite de subdiretórios ou pastas de 32000, se você achava isso um incômodo, os limites serão apenas o do espaço fornecido pelo disco.
  • Alocação tardia: ext4 usa uma técnica de execução do sistema de arquivos chamado allocate-on-flush, também conhecida como a atribuição de atraso. Isso melhora o desempenho e reduz a fragmentação, melhorando a alocação de blocos decisões com base no tamanho do arquivo.
  • O ext4 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como o tune2fs, mke2fs, debugfs e e2fsck.

Principais desvantagens

1. Alocação tardia e potencial perda de dados:

Com as mudanças de alocação atrasada, este recurso representa algum risco adicional de perda de dados nos casos em que o sistema trava antes que todos os dados tenham sido gravados no disco.

Devido a isto, o ext4, na versão 2.6.30 do kernel GNU/Linux, detecta automaticamente estes casos e reverte para o comportamento antigo. O cenário típico em que isso pode ocorrer é um programa que substitui o conteúdo de um arquivo sem forçar uma gravação para o disco com sync.

2. Criação do sistema de arquivos:

Assim como no ex3, o ext4 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.

O sistema de arquivos ext4, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportá-lo e este recurso foi integrado a partir da versão 3 do mesmo, por isso o journal não é tão eficaz, nem no ext3 e no ext4, apesar que o último mencionado teve melhorias.

E quando o journal falhar, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.

Atualmente o ext4 é bem rápido, tem um ótimo desempenho, mas seu journal pode deixar a desejar quanto à tolerância de falhas, apesar que o mesmo teve melhorias e resiste bem.

Sistema de arquivos XFS

O sistema de arquivos XFS é considerado por muitos de alto desempenho, é um sistema de arquivos de 64 bits sendo compatível com sistemas de 32 bits. Foi desenvolvido inicialmente para o SO IRIX, depois portado para o kernel GNU/Linux.

O kernel e a maioria dos sistemas GNU/Linux dão suporte durante a instalação para usar o XFS como sistema de arquivos de suas partições, e assim, como os outros sistemas de arquivos apresentados até agora, possui journaling.

Principais vantagens

  • Possui journaling em sua estrutura, porém o journal no XFS se comporta de forma similar a outros sistemas de arquivos, mantendo somente a gravação dos metadados dos arquivos no journaling, fazendo com que a consistência do sistema de arquivos como um todo fique preservada.

    Diferente do que faz outros sistemas de arquivos, que se um arquivo ficar corrompido, o sistema fica inacessível, porém, se um arquivo estiver sendo usado e as alterações nos metadados não forem gravadas antes de um erro ou falha (falta de energia por exemplo), poderá ficar corrompido, já que seu conteúdo não foi salvo e os metadados não foram colocados no journal antes da gravação do arquivo no sistema de arquivos.

  • É um sistema de arquivos de 64 bits compatível com sistemas de 32 bits também.
  • Em sistemas 64 bits há um limite de tamanho de 8 EiB para cada arquivo, já em sistema de 32 bits o tamanho máximo do volume ou arquivo é limitado a 16 TiB.
  • Tamanhos de blocos variáveis: Tamanho de blocos do sistema representa a unidade de alocação mínima. XFS permite que o sistema de arquivos seja criado com tamanhos de blocos que variam entre 512 bytes e 64 kilobytes, permitindo que o sistema de arquivos ajuste-o para o uso esperado.

    Quando está trabalhando com muitos arquivos pequenos, um tamanho de bloco pequeno é o ideal, mas para um sistema lidando principalmente com arquivos grandes, um tamanho de bloco maior pode proporcionar uma vantagem quanto ao desempenho.

  • A desfragmentação online: Embora o XFS use alocação com atraso, isso melhora significativamente a resistência do sistema de arquivos para os problemas de fragmentação. XFS fornece um utilitário de desfragmentação que pode desfragmentar os arquivos com o sistema de arquivos em uso.
  • A criação do sistema de arquivos XFS é muito rápida.
  • Redimensionamento online: XFS oferece a ‘xfs_growfs’, utilitário para executar o redimensionamento online de sistemas de arquivos XFS.

    Espaço onde se encontra o sistemas de arquivos XFS podem ser alterados desde que haja espaço restante não alocado no dispositivo para adicionar ao XFS. Este recurso é normalmente usado em conjunto com o gerenciamento de volume, caso contrário a partição que mantém o sistema de arquivos terá que ser ampliada separadamente.

  • Utilitários para gerenciamento do sistema de arquivos inclusos no xfsprogs, tais para checagem do mesmo, aplicação do sistema de arquivos, ajustes no sistema de arquivos entre outros.
  • Cotas de disco: Cotas para sistemas de arquivos XFS são ativadas quando o sistema de arquivos é montado, diferente de outros sistemas de arquivos que na maioria exigem serem montados primeiro para depois ativar a quota com o quotaon.
  • Trabalha muito bem com arquivos grandes (leitura e gravação), principalmente em sistemas que armazenam muitos arquivos de grande tamanho. Lembre-se o XFS foi desenvolvido para trabalhar em grandes sistemas, principalmente de 64 bits.

Principais desvantagens

  • Redimensionamento do XFS não pode ser usado para diminuir o tamanho do mesmo, apenas aumentar.
  • Operações usando metadados em XFS são muito lentas do que com outros sistemas de arquivos, produzindo mau desempenho em operações como deleções em massa de grandes números de arquivos pequenos.
Sistema de arquivos ReiserFS

O sistema de arquivos ReiserFS foi criado por Hans Reiser e pode ser usado pelas distribuições GNU/Linux, sendo que algumas dão bom suporte durante a instalação e outras não. Sua versão atual é a 3.6.x. O ReiserFS foi o primeiro sistema de arquivos com suporte a journaling incluído no núcleo do GNU/Linux.

Algo muito interessante no ReiserFS é suporte ao journaling implantado desde o início e não depois de ter sido desenvolvido (como foi feito no extFS). Isso garante que o ReiserFS trabalhe melhor com o journal, possibilitando uma tolerância contra falhas mais eficaz.

Principais vantagens

  • Suporte a journaling, o mesmo foi integrado desde de seu desenvolvimento. Diferentemente do que acontece no ext3 e ext4, que foi implementado em versões posteriores após o desenvolvimento da primeira versão.

    O extFS permite trabalhar em vários modos de operação, já no ReiserFS é importante frisar que as técnicas de journaling limitam-se, por padrão, aos metadados (conjuntos de informação sobre arquivos, como tamanho, proprietário, permissões, data de alteração etc). Contudo, o usuário poderá alterar seu modo de operação para journal ou writeback, pois o ReiserFS também suporta os três modos de operação assim como no extFS, versão 3 e 4. Como o journaling está presente desde o inicio, faz com que esse sistema de arquivos seja eficiente na recuperação do sistema operacional como um todo em caso de problemas.

    No caso de um desligamento incorreto do sistema, o ReiserFS é capaz de recuperar a consistência do sistema de arquivos em pouco tempo e a possibilidade de perda de pastas ou partições é reduzida.

    Em compensação, os arquivos que eventualmente estiverem sendo gravados no exato momento em que acabou a energia, ficarão com seus dados corrompidos, haverá acesso aos arquivos normalmente, mas o conteúdo estará truncado ou incompleto.

  • Organização dos objetos do sistema de arquivos em uma estrutura de dados chamada B+Trees (árvores B+). Neste esquema, os dados são fixados em posições organizadas por divisões denominadas folhas.

    As folhas por sua vez são organizadas por nós, chamados de sub-árvores, que estão ligados a um nó raiz. Esse processo organizacional é mais complexo, porém apresenta performance superior na gravação e no acesso aos dados se comparado a outros sistemas de arquivos.

  • Alocação dinâmica de inodes (em poucas palavras, inodes são estruturas que contém informações sobre os arquivos), diminuindo o desperdício de espaço. Outros sistemas de arquivos têm blocos de tamanho fixo para alocação, assim, se não for necessário usar um bloco inteiro, o espaço restante fica em desuso. No ReiserFS a alocação é feita com base no tamanho do arquivo.
  • ReiserFS tem progsreiserfs, que é um conjunto de utilitários para gerenciamento de sistema de arquivos, para checagem, formatação, depuração etc.
  • A formatação em ReiserFS é muito rápida.

Principais desvantagens

  • Uma desvantagem do ReiserFS é seu consumo de CPU muito elevado, chegando a usar até 99% quando a atividade de disco é elevada.
  • O futuro do ReiserFS é atualmente dado como incerto, em virtude da prisão, em 10 de Outubro de 2006, de Hans Reiser, seu criador, e sua condenação em 28 de Abril de 2008 pelo assassinato de sua mulher no início de Setembro de 2006.

Atualmente, devido à paralisação das atividades da Namesys, que é sua principal desenvolvedora junto com Hans Reiser, o projeto ReiserFS está armazenado em kernel.org.

O ReiserFS tem um nova versão, que é a 4, mas a mesma ainda não está inclusa no kernel versão 3.x.x, que atualmente é 3.4.2 no momento da criação deste artigo, pois os desenvolvedores afirmam que o Reiser4 não segue o padrão GNU/Linux de decodificação.

Para mais informações sobre o Reiser4, acesse link:

Sistema de arquivos JFS

O JFS foi criado com o propósito principal de ser utilizado em servidores que deveriam usar poucos recursos do processador, e ser capaz de ser redimensionado mesmo em uso. JFS é um sistema de 64 bits, assim como XFS, onde existem duas versões: JFS1 e JFS2. No pinguim é usada a versão 2.

JFS está disponível na maioria das distros, assim como outros, mas durante a instalação o FS padrão, em sua maioria, é o ext4.

Principais vantagens

  • Reparação muito eficaz de um disco com badblocks, ele consegue marcar os setores defeituosos com muita precisão, algo que outros sistemas de arquivos para Linux não fazem.
  • Criação do sistema de arquivos muito rápida, desde que não inclua para marcar os badblocks existentes do disco, pois se fizer isso vai demorar bastante.
  • Possui vários utilitários para gerenciar o sistema de arquivos, todos eles inclusos no jfsutils, para aplicação e verificação de integridade do sistema de arquivos.
  • Baixo consumo do processador.
  • Suporte a journaling: O JFS usa um journal para manter somente a consistência dos metadados, ou seja, grava somente os metadados dos arquivos que sofrerão ações como modificação, por exemplo. Assim, apenas consistência de metadados (e não o conteúdo de arquivo) pode ser assegurado no caso de desligamento inadequado. Este é também o comportamento de XFS . Ext3 e ext4, por outro lado, usam o journal para gravar os metadados e os dados, apesar de ter outros modos de operação.
  • Alocação dinâmica de inodes: JFS aloca dinamicamente espaço em disco.

Principais desvantagens

  • Taxas de transferências baixas, nunca espere transferências com alta velocidade, pois o mesmo é lento.
  • Foi desenvolvido com o propósito principal de trabalhar com arquivos grandes e não trabalha bem com arquivos pequenos. Na criação e desempacotamento de arquivos sua velocidade é baixa.
  • O tamanho de uma partição e arquivo com o sistema de arquivos JFS aplicado só abriga 2 terabytes de espaço no total.
Benchmark básico dos sistemas de arquivos

Depois de tantas informações sobre cada sistema de arquivos abordado, você pode ficar com, no mínimo, um pouco de curiosidade de saber o desempenho de cada um deles em teste.

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

ESCLARECIMENTO: Para este Benchmark não fiz otimização em nenhum dos sistemas de arquivos, todos foram instalados com suas opções padrões. O SO usado para testar foi o Debian 6, rodando em uma máquina com processador Intel Core 2 Duo e espaço em memória de 4 Gigas, além de um disco SATA Samsung.

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

Primeiro teste

Trata-se de criar um arquivo de 10 Gigabytes de tamanho em cada sistema de arquivos usando o comando dd, todos concluíram o teste em minutos. Veja o resultado no gráfico abaixo:

Neste teste o mais veloz foi ext4, seguido de ext3 e logo depois XFS, seguido de ReiserFS e em último ficou o JFS.

Segundo teste

Foi desempacotado um arquivo do kernel 3.4 com tamanho de 77 Megas e todos concluíram a tarefa em menos de um minuto, ou seja, concluíram em segundos. Veja o resultado no gráfico abaixo:

Neste segundo teste, ext4 também foi mais rápido, mas a diferença não foi tanta para ext3 e ReiserFS, XFS veio logo atrás, e no último lugar, mais uma vez ficou JFS.

Terceiro teste

Fiz uso de um script para criar 30 mil arquivos de texto simples, sem conteúdo, e todos concluíram o trabalho em poucos segundos, veja o resultado no gráfico abaixo:

Nesta terceira rodada, o mais rápido foi ReiserFS, seguido de pertinho por ext4 e ext3, e mais uma vez, JFS foi o mais lento.

Quarto teste

Fiz uma listagem de todos os 30 mil arquivos criados no teste anterior, e mais uma vez todos concluíram em poucos segundos. Veja o resultado no gráfico abaixo:

Nesta rodada, o ext3 foi muito mais rápido que os outros, concluindo o trabalho em menos de um segundo, logo depois veio ext4, ReiserFS, JFS e XFS, com pouco tempo de diferença entre eles.

Quinto teste

Fiz a remoção de todos os 30 mil arquivos criados anteriormente, e mais uma vez todos concluíram o teste em menos de um minuto, veja o resultado no gráfico abaixo:

Neste teste o mais rápido foi ext4, seguido de ext3 e ReiserFS, o mais lento foi XFS, aliás, muito lento em comparação com os outros.

Sexto teste

Removi o diretório do kernel 3.4 e todos seus arquivos e subdiretórios criados após a descompactação, e o teste foi concluído em segundos. Veja o resultado no gráfico abaixo:

Neste teste o ext3 e ext4 foram absurdamente mais rápidos, respectivamente, com um pouquinho de tempo a mais, o ReiserFS demostrou muita velocidade. O JFS foi muito lento.

Sétimo teste

Fiz uso de um script para criar 30 mil diretórios vazios e a tarefa levou menos de um minuto para ser concluída, mais uma vez (foi concluída em segundos). Veja o resultado no gráfico abaixo:

Neste teste houve um certo equilíbrio na velocidade de término de tarefa de cada um, dupla exts foram um pouco mais velozes que ReiserFS e JFS, e XFS foi o mais lento mais um vez.

Oitavo teste

Removi os diretórios criados e o término da tarefa foi em segundos também:

Neste último teste os sistemas de arquivos ext4, ext3 e ReiserFS foram absurdamente mais rápidos, acabando a tarefa em menos de um segundo cada.

Você pode ver também um benchmark feito pela Phoronix acessando o link abaixo:

Nota-se neste benchmark básico realizado por mim, que os sistemas mais velozes foram ext4 e ext3, seguido do ReiserFS e depois XFS e por último, o JFS.

Tenho que levar em conta que não foi feito nenhum tipo de personalização no sistema de arquivos aplicado, tal como: aumento de tamanho do arquivo do journaling, ou journaling externo, por exemplo. Ou seja, nenhum sistema de arquivos foi turbinado.

Considerações finais

Todos os testes realizados e mostrados na página anterior foram baseados na velocidade de término de cada tarefa, contudo, não faça a escolha do sistema de arquivos somente pelo desempenho, leve em consideração as características positivas e negativas de cada um.

Quando o assunto é sistema de arquivos no GNU/Linux, é inevitável as comparações entre o ReiserFS, XFS, ext4 e o ext3, além do JFS, que é menos usado. Nada mais natural, afinal, cada administrador de sistemas e ou redes e até mesmo usuários busca qual é o melhor para suas necessidades.

Apontar qual realmente é melhor não é uma tarefa fácil. Há vários comparativos na Internet que tentam oferecer esta resposta, mas na minha opinião, a melhor coisa a fazer é testar os sistemas de arquivos que lhe atraíram para definir qual mais lhe agrada.

Definitivamente, o uso de sistemas de arquivos sem suporte a journaling, ou algum recurso similar, para tolerância de falhas e erros não é recomendável de usar, pois pode deixá-lo na mão.

NOTA: Não incluí o Btrfs, pois o mesmo é considerado instável e não é aconselhável o seu uso em produção, e ainda está em desenvolvimento constante para ser aprimorado.

Se deseja mais informações sobre o mesmo, leia o artigo:

Recomendação de uso

Se quer desempenho, recomendo ext4, pois o mesmo mostra-se muito rápido, e o suporte dele no kernel (usado como default nas instalações até então de muitas distros) é muito bom. E ext3, que apesar de ser considerado obsoleto por muitos, é bem estável e ainda é rápido também, porém, o mesmo não tem tanta eficácia com o journaling (como explicado durante o artigo).

Para isso recomendo ReiserFS e XFS, pois estou usando-os a um bom tempo, e os mesmos até o momento não apresentaram nenhum problema, mesmo já passando por desligamentos inesperados e ambos terem um desempenho muito bom, cada um com suas vantagens. XFS trabalha melhor com arquivos grandes e ReiserFS com arquivos pequenos.

São apenas recomendações, porém, recomendo que teste e veja qual é o que mais o agrada no quesito que deseja e necessita.

Concluindo, menciono mais uma vez que o journal é para tolerar falhas e erros, e não protege 100% contra perda de dados.

Tunando sistemas de arquivos para GNU/Linux

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em Tunando sistemas de arquivos para GNU/Linux
ago 092012
 
Introdução

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:

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

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

Tunando o sistema de arquivos ReiserFS

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

/dev/sda1     /     reiserfs    notail,rw,data=writeback,relatim e    0    1

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

/dev/sda1     /     reiserfs    notail,rw,data=writeback,noatim e,nodiratime    0    1

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:

/dev/sda1     /     reiserfs    notail,rw,relatime,barrier=flush& nbsp;   0    1

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

/dev/sda1     /     reiserfs    notail,rw,sync,barrier=flush  ;   0    1

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

/dev/sda1     /     reiserfs    notail,rw,data=writeback,relatim e    0    1

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

/dev/sda1     /     reiserfs    notail,rw,data=writeback,noatim e,nodiratime    0    1

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

/dev/sda1     /     reiserfs    notail,rw,sync,barrier=flush  ;   0    1

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.

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

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

Tunando o sistema de arquivos JFS

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:

UUID=b8ff3909-37f7-431e-a634-873842017335 /     jfs   rw,errors=remount-ro,relatime

UUID=22a6a838-e8af-450d-887c-f2c40c6bbfa3 /home     jfs   rw,relatime

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:

UUID=b8ff3909-37f7-431e-a634-873842017335 /     jfs   rw,errors=remount-ro,noatime,nodiratime

UUID=22a6a838-e8af-450d-887c-f2c40c6bbfa3 /home     jfs   rw,noatime,nodiratime

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

UUID=b8ff3909-37f7-431e-a634-873842017335 /     jfs   rw,errors=remount-ro,relatime

UUID=22a6a838-e8af-450d-887c-f2c40c6bbfa3 /home     jfs   rw,relatime

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

UUID=b8ff3909-37f7-431e-a634-873842017335 /     jfs   rw,errors=remount-ro,noatime,nodiratime

UUID=22a6a838-e8af-450d-887c-f2c40c6bbfa3 /home     jfs   rw,noatime,nodiratime

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.

Tunando os sistemas de arquivos ext3 e ext4

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

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

Apresentando particionamento usado para aplicar as alterações:

  • Partição: /dev/sda1 com sistema de arquivos ext3 – Diretório root “/”;
  • Partição: /dev/sda2 com sistema de aquivos ext4 – Diretório home “/home”;
  • Partição: /dev/sda5 – Swap;
  • Partição: /dev/sdb1 – Partição usada para armazenar o journal externo da partição /dev/sda1;
  • Partição: /dev/sdb2 – Partição usada para armazenar o journal externo da partição /dev/sda2.

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

Tunando o ext3 e ext4 usando journal externo

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

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

# tune2fs -l /dev/sda1 |grep -i “block size”
# tune2fs -l /dev/sda2 |grep -i “block size”

É necessário saber qual o tamanho do bloco do sistema de arquivos de cada partição que terá seu journal externo, porque cada partição que armazenará os logs precisará ter o mesmo tamanho de bloco.

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

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

As opções passadas ao comando mke2fs foram:

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

E por fim, o número indicado no fim é o tamanho do journal em blocos. Para calcular corretamente o tamanho do journal armazenado, tenha em mente que 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

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

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

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

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

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

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

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

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

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

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

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

commit

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

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

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

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

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

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

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

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

# tune2fs -o journal_data_writeback /dev/sda2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tunando o ext3 e ext4 usando journal interno

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

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

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

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

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

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

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

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

rootfkags=data=writeback

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

GRUB_CMDLINE_LINUX=””

Assim:

GRUB_CMDLINE_LINUX=”rootfkags=data=writeback”

E em seguida, execute como root o comando:

# update-grub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rootfkags=data=journal

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

GRUB_CMDLINE_LINUX=””

Para:

GRUB_CMDLINE_LINUX=”rootfkags=data=writeback”

E depois, executar o comando:

# update-grub

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

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

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

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

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

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

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

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

Para esta série de testes de desempenho, usei uma máquina com:

  • Processador Intel® Core™2 Duo;
  • Placa mãe ASUS;
  • Memória RAM com capacidade 4 GB;
  • HD Samsumg SATA 3;
  • Sistema Debian 6.0.5;
  • kernel 3.2.0-0.bpo.2-amd64.

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

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

– ReiserFS:

  • Journal externo;
  • As opções para alterar o comportamento ReiserFS foram adicionadas ao “/etc/fstab”:
    notail,rw,data=writeback,relatime

– XFS:

  • Journal externo, criado com o seguinte comando:

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

  • As opções para alterar o comportamento para XFS foram adicionas ao “/etc/fstab”:
    rw,relatime,attr2,nobarrier,allocsize=64m,logdev=/dev/sda7

– JFS:

  • Journal externo;
  • As opções para alterar o comportamento para JFS foram adicionadas ao “/etc/fstab”:
    rw,relatime

– ext3:

  • Journal externo, o tamanho do journal criado é de 105500;
  • As opções para alterar o comportamento para ext3 foram adicionadas ao “/etc/fstab”:
    errors=continue,rw,relatime,commit=30

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

    # tune2fs -o journal_data_writeback /dev/sda8

– ext4:

  • Journal externo, o tamanho do journal criado é de 105500;
  • As opções para alterar o comportamento para ext3 foram adicionadas ao “/etc/fstab”:
    errors=remount-ro,rw,relatime,commit=30

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

    # tune2fs -o journal_data_writeback /dev/sda8

Primeiro teste

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

Veja no gráfico abaixo o resultado:

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

Segundo teste

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

Veja no gráfico abaixo o resultado:

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

Terceiro teste

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

Veja no gráfico abaixo o resultado:

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

Quarto teste

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

Veja no gráfico abaixo o resultado:

Os sistemas ext4 e XFS foram, respectivamente, mais rápidos que os outro F.S. neste teste.

Quinto teste

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

Veja no gráfico abaixo o resultado:

Neste teste, JFS e XFS foram os mais rápidos, respectivamente. ReiserFS foi o mais lento de todos.

Sexto teste

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

Veja no gráfico abaixo o resultado:

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

Sétimo teste

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

Veja no gráfico abaixo o resultado:

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

Oitavo teste

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

Veja no gráfico abaixo o resultado:

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

Nono teste

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

Veja no gráfico abaixo o resultado:

ReiserFS foi o mais rápido outra vez, seguido de JFS e XFS, que finalizaram o trabalho com o mesmo tempo. O ext4 foi o que levou mais tempo.

Décimo teste

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

Veja no gráfico abaixo o resultado:

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

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

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

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

Considerações finais

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.