Tunando o ext4 para Desempenho! Revisto, ampliado e ainda mais rápido e seguro!

[rudregues]

Rapazes. Se vocês conseguirem esse feito vai ser do Baralho!

Agora, testem isso aí num sistema que não seja de produção né!

Seria esse comando?

Código Selecionar Expandir

tune2fs -t ext4 -i 47d -c 27 -O dir_index /dev/sdxy
-t ext4: sistema de arquivos ext4
-i 47d: checar a cada 47 dias
-c 27: checar a cada 27 montagens
-O dir_index: otimização por hashed b-trees

-O [^]feature[,...]
   Set or clear the indicated filesystem features (options) in the filesystem. More than one filesystem feature can be cleared or set by separating features with commas. Filesystem features prefixed with a caret character ('^') will be cleared in the filesystem's superblock; filesystem features without a prefix character or prefixed with a plus character ('+') will be added to the filesystem.
The following filesystem features can be set or cleared using
   tune2fs:
dir_index
   Use hashed b-trees to speed up lookups in large directories.

fonte: http://linux.die.net/man/8/tune2fs


EDIT: parece que é isso mesmo, mas de acordo com http://linuxpoison.blogspot.tw/2007/10/tune-your-ext3-filesystem.html não é o suficiente, é preciso rodar e2fsck na partição com o parâmetro -D para otimizar os diretórios pra o dir_index.
Acho que ele quis dizer que deve-se rodar ao menos uma vez o comando e2fsck para ativar essa otimização e depois num precisa mais, mas num tenho certeza. Talvez tenha-se que levar em consideração que é um post de 2007 e de repente não seja mais necessário rodar o e2fsck uma vez para essa suposta "ativação".

[hiltongil]

Rapazes. Se vocês conseguirem esse feito vai ser do Baralho!

Agora, testem isso aí num sistema que não seja de produção né!

Seria esse comando?

Código Selecionar Expandir

tune2fs -t ext4 -i 47d -c 27 -O dir_index /dev/sdxy
-t ext4: sistema de arquivos ext4
-i 47d: checar a cada 47 dias
-c 27: checar a cada 27 montagens
-O dir_index: otimização por hashed b-trees

-O [^]feature[,...]
   Set or clear the indicated filesystem features (options) in the filesystem. More than one filesystem feature can be cleared or set by separating features with commas. Filesystem features prefixed with a caret character ('^') will be cleared in the filesystem's superblock; filesystem features without a prefix character or prefixed with a plus character ('+') will be added to the filesystem.
The following filesystem features can be set or cleared using
   tune2fs:
dir_index
   Use hashed b-trees to speed up lookups in large directories.

fonte: http://linux.die.net/man/8/tune2fs


EDIT: parece que é isso mesmo, mas de acordo com http://linuxpoison.blogspot.tw/2007/10/tune-your-ext3-filesystem.html não é o suficiente, é preciso rodar e2fsck na partição com o parâmetro -D para otimizar os diretórios pra o dir_index.
Acho que ele quis dizer que deve-se rodar ao menos uma vez o comando e2fsck para ativar essa otimização e depois num precisa mais, mas num tenho certeza. Talvez tenha-se que levar em consideração que é um post de 2007 e de repente não seja mais necessário rodar o e2fsck uma vez para essa suposta "ativação".

Bah você conseguiu bastante material.
Vou ler e tentar implementar e testar alguma coisa dai coloco os resultados por aqui.
Valeu pela contribuição.

[galactus]

Hoje quando você manda formatar com ext4, o dir_index já deve estar incluído na formatação padrão. Pra ver se ele foi "ativado" é simples, faz um

tune2fs -l /dev/sdxy


E dá uma olhada na linha

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize


Aí estão listadas todas as propriedades deste ext4.

A opção -D do fsck otimiza os diretórios refazendo a lista do índice de diretórios (dir_index). Por isso vocês já devem ter notado que fica mais rápido para aparecer os diretórios depois de usar este comando, principalmente num sistema de arquivos com um monte de diretórios que foram deletados ou gravados.
É bom fazer isso de tempos em tempos no seu sistema já instalado.

[hiltongil]

Então rodei o comando

tune2fs -t ext4 -i 47d -c 27 -O dir_index /dev/sdxy

Primeiro informou que a opção -t ext4 era inválida. Removi ela e rodei

tune2fs -i 3d -c 7 -O dir_index /dev/sdxy

Hoje ao reiniciar o tune2fs fez a checagem e pau. Não carregou. Tive que pressionar ctrl+d para prosseguir com a inicialização. Agora rodei o comando

tune2fs -i 3d -c 7 /dev/sdxy

Na próxima oportunidade que rodar quero ver se o carregamento se dá de forma automática.

[Cybereu]

Já faz algumas versões do ubuntu que não consigo mais usar os tweaks, sempre aparece mensagens de erros no boot:
Errors found while checking disk drive for /

Olá. Quais Tweaks?

Sua foto está muito pequena não consegui ler a  mensagem na foto.  Existe um Bug na montagem do Ubuntu, já documentada, dizem que corrigiram na versão 13.04. Erros na motagem principalmente do diretório/partição tmp acontecem muito por causa desse BUG.

Venho usando as alterações em alguns dos meus sistema ext4 com sucesso.

Estou tentando usar um SSD com journal separado em uma particao, ja faz algumas versoes do Ubuntu que nao consigo mais faze-lo sem dar erro no boot sobre erro de montagem do tmp por exemplo, no momento estou tentando com o Ubuntu 13.04.


Edit: Encontrei uns benchmarks mostrando como modificar o fstab pode ser útil:
http://www.howtogeek.com/62761/how-to-tweak-your-ssd-in-ubuntu-for-better-performance/

Edit 2: Nesse site o autor recomenda não habilitar o TRIM no fstab (discard).

Código Selecionar Expandir

7.3. Another widely used method for automatic TRIM is to add the option discard to /etc/fstab, for the line for your root partition and for possible other Linux partitions that are being mentioned there.

Note: do not add it to the line for the swap partition, as that's already being trimmed automatically by the system by default, during the boot process!

The disadvantage of this method is, that it may cause the system to slow down. Because it forces the system to apply TRIM instantly on every file deletion. That's why this method is not my favourite.

[galactus]

Obrigado pelas dicas Cybereu, mas porque você não faz um tuto de como tunar um SSD? É que eu não tenho nenhum SSD, daí não posso testar e nem confirmar essas mudanças!

[hiltongil]

Bom dia pessoal segue abaixo o link da Linux Fundation sobre tunagem de sistemas de arquivo.
http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning_Methodology_v1.0.pdf

[galactus]

Olá hiltongil. O artigo é muito interessante, principalmente porque eles testaram em hardware para dispositivos móveis, um processador ARM e os cartões SD.

Ele não mostra nenhuma dica de tunagem nova, mas sim o desempenho dos sistemas de arquivos testados em várias situações.

Gostei de saber que a opção nobarrier para o ext4 não vai aumentar o risco de perda de dados em uma queda de energia!

Já eperava que o BTRFS "virasse farelo" com as quedas de energia já que a ferramenta de checagem do sistema de arquivos ainda engatinha!

Obrigado por ter compartilhado o artigo com a gente!

[hiltongil]

Olá hiltongil. O artigo é muito interessante, principalmente porque eles testaram em hardware para dispositivos móveis, um processador ARM e os cartões SD.

Ele não mostra nenhuma dica de tunagem nova, mas sim o desempenho dos sistemas de arquivos testados em várias situações.

Gostei de saber que a opção nobarrier para o ext4 não vai aumentar o risco de perda de dados em uma queda de energia!

Já eperava que o BTRFS "virasse farelo" com as quedas de energia já que a ferramenta de checagem do sistema de arquivos ainda engatinha!

Obrigado por ter compartilhado o artigo com a gente!

Pois é Galactus. Tô esperançoso em relação ao BTRFS. Se ele tivesse a velocidade e resistência a falhas do Ext4 com os recursos de CoW seria ótimo. Depois que vi o vídeo do OpenSUSE com o snapper fiquei empolgado. Procurei alguma GUI que facilitasse a manutenção de snapshots do BTRFS mas não tive êxito. Seria legal ter um programa que fizesse isso algo como o Nexenta tem (http://en.wikipedia.org/wiki/Nexenta_OS) um Time Machine. Aliás, alguém aqui já teve alguma experiência com ZFS no Linux?

[Xterminator]

Olá hiltongil. O artigo é muito interessante, principalmente porque eles testaram em hardware para dispositivos móveis, um processador ARM e os cartões SD.

Ele não mostra nenhuma dica de tunagem nova, mas sim o desempenho dos sistemas de arquivos testados em várias situações.

Gostei de saber que a opção nobarrier para o ext4 não vai aumentar o risco de perda de dados em uma queda de energia!

Já eperava que o BTRFS "virasse farelo" com as quedas de energia já que a ferramenta de checagem do sistema de arquivos ainda engatinha!

Obrigado por ter compartilhado o artigo com a gente!

E eu ainda continuo usando o bom e velho Reiserfs3 ;-)
que para uso doméstico ainda acho uma das melhores opções, experimentei o btrfs por um tempo
e tenho usado Ext4 no Fedora, em algumas operações simples o Reiser chega a ser 2 vezes mais rápido que o EXT4
estes dias por exemplo tive que mover e redimensionar 2 partições com cerca de 15GB, uma de cada tipo, o EXT4 demorou muito para fazer o processo
não lembro exatamente o tempo, mas sei que quando fiz no reiser o processo foi muito mais rápido, digamos que EXT4 10 minutos e reiserfs 3 minutos.

[galactus]

Aliás, alguém aqui já teve alguma experiência com ZFS no Linux?

Eu nunca usei o ZFS no Linux. Só com FreeBSD mesmo. Num servidor de arquivos NAS com RAID 5 e o ZFS. Das soluções que já havia usado ou visto, servidor de arquivos Windows ou Linux,  essa sem dúvida foi a melhor em matéria de resistir a muitas requisições como se não fosse nada! Só nas taxas de transferências é que ele não era o mais rápido. Mas em compensação em resisitir a um monte de coisas ao mesmo tempo e a sua segurança, era realmente muito bom.

Nós simulamos a perda de um HD e o sistema continua operando, mais lento é claro, mas continua funcionando. Formatei o HD e simulei ter colocado um disco novo, zerado. Ele refez o Pool dos dados, demorou pra cacete, mas refez tudo bonitinho e com o sistema ainda em uso.

[galactus]

E eu ainda continuo usando o bom e velho Reiserfs3 ;-)
que para uso doméstico ainda acho uma das melhores opções, experimentei o btrfs por um tempo
e tenho usado Ext4 no Fedora, em algumas operações simples o Reiser chega a ser 2 vezes mais rápido que o EXT4
estes dias por exemplo tive que mover e redimensionar 2 partições com cerca de 15GB, uma de cada tipo, o EXT4 demorou muito para fazer o processo
não lembro exatamente o tempo, mas sei que quando fiz no reiser o processo foi muito mais rápido, digamos que EXT4 10 minutos e reiserfs 3 minutos.

O Reiserfs é o mais rápido para arquivos pequenos, sem dúvida, como para a maioria dos mortais, seus dados são pequenos, você sente o sistema mais rápido com o Reiserfs. Mas é só mudar o cenário, coloque um servidor de multimidia com Raiserfs e coloca vários usuários assistindo vídeos nele, que você vai ver que ele pede água logo.  Para isso o XFS é muito superior. 

Cada sistema de arquivos tem seus prós e contras. O ideal seria poder usar cada sistema de arquivos para uma situação específica, naquilo que ele rende mais.
Mas como o desenvolvimento dele parou, assim como do excelente JFS, e os dados de uma forma geral aumentaram muito de tamanho, acaba que temos que mudar um dia de sistema de arquivos.

Outra coisa que praticamente é a pá de cal para o Reiserfs3, ele é o que mais consome recursos do processador! Em tempos de dispositivos móveis com processadores ARM....

[Xterminator]

E eu ainda continuo usando o bom e velho Reiserfs3 ;-)
que para uso doméstico ainda acho uma das melhores opções, experimentei o btrfs por um tempo
e tenho usado Ext4 no Fedora, em algumas operações simples o Reiser chega a ser 2 vezes mais rápido que o EXT4
estes dias por exemplo tive que mover e redimensionar 2 partições com cerca de 15GB, uma de cada tipo, o EXT4 demorou muito para fazer o processo
não lembro exatamente o tempo, mas sei que quando fiz no reiser o processo foi muito mais rápido, digamos que EXT4 10 minutos e reiserfs 3 minutos.

O Reiserfs é o mais rápido para arquivos pequenos, sem dúvida, como para a maioria dos mortais, seus dados são pequenos, você sente o sistema mais rápido com o Reiserfs. Mas é só mudar o cenário, coloque um servidor de multimidia com Raiserfs e coloca vários usuários assistindo vídeos nele, que você vai ver que ele pede água logo.  Para isso o XFS é muito superior. 

Cada sistema de arquivos tem seus prós e contras. O ideal seria poder usar cada sistema de arquivos para uma situação específica, naquilo que ele rende mais.
Mas como o desenvolvimento dele parou, assim como do excelente JFS, e os dados de uma forma geral aumentaram muito de tamanho, acaba que temos que mudar um dia de sistema de arquivos.

Outra coisa que praticamente é a pá de cal para o Reiserfs3, ele é o que mais consome recursos do processador! Em tempos de dispositivos móveis com processadores ARM....

Realmente você tem toda razão eu utilizo reiserfs "somente" para a partição do sistema /home por guardar maiores arquivos eu deixo em EXT4, quanto ao consumo de CPU para o uso que faço do computador considero normal, nunca cheguei a ter picos altos de consumo.

[hiltongil]

Utilizo essa dica de tunning do ext4 desde que a conheci.

E andei pensando se não havia alguma forma de automatizar o comando

#fsck -t ext4 -f -D /dev/sdxy

para que ele fosse executado a cada "x" dias, semanas, meses.

Como o comando deve ser rodado com o sistema desmontado não me veio a cabeça alguma forma de automatizar via script. Dai lembrei que o tune2fs checa a integridade do filesystem a cada 180 dias ou 30 montagens (dependendo do sistema). Nisso me veio a dúvida: Alguém sabe se tem como configurar essa checagem que o tune2fs faz a cada "x" dias para que ele execute o comando de otimização?

Difícil essa viu. Tem como alterar a cada quantos boots ele vai fazer a checagem, diminuir, aumentar ou até mesmo desabilitar as checagens padrões. Mas alterar essa checagem padrão via script....

Como ele vai ler esse script se a partição raiz tem que estar desmontada?   

Então esses dias vi um artigo: http://www.devin.com.br/auto-fsck/
E pensei se talvez a solução não estivesse por aqui...

Nesse artigo que mencionei o autor informa que há como colocar a opçãp "-p" como regra a ser seguida no fsck ao inicializar. Daí pensei: Se ele aceita a opção "-p" será que não aceitaria a opção: "-t ext4 -f -D /dev/sdxy"

Rodei aqui e não tive nenhuma mensagem de erro. Agora a dúvida: Como saber se o comando foi executado correto? Ou seja, como saber se quando reiniciei o sistema o comando executado pelos o fsck foi -t ext4 -f -D /dev/sdxy

Alguma ideia de como verificar isso galactus? Pois, se o comando tiver rodado certinho. Encontramos a solução, pois, bastará inserir um agendamento no cron para a cada "x" dias gerar os arquivos /fsck e /fsckoption e acho que automatizamos essa otimização sem necessidade de rodar o comando através de um livecd/pen

[galactus]

Infelizmente não tenho ideia ainda hiltongil.

Mas vou procurar, dar uma pesquisada pra saber. Qualquer novidade eu posto aqui.