Está é uma tradução livre do texto originalmente publicado aqui: http://kernelnewbies.org/Ext4. Meu inglês não é muito bom, e por essa razão traduzi este texto, e outros textos que podem vir a ser postado em meu blog, para melhorar ele. Caso encontrem erros, o que é provável que aconteça, me informe (andreoandre <> gmail <dot> com ) para corrigir e manter o texto atualizado.
Introdução
Ext4 é a evolução do sistema de arquivos mais usados no Linux, o Ext3. De muitas maneiras, Ext4 é uma profunda melhoria sobre o Ext3, sendo o Ext3, com muitas melhorias frente o Ext2. No Ext3 foi principalmente a adição de Journaling sobre o Ext2, mas Ext4 teve mudanças importantes na estrutura do sistema de arquivos destinado ao armazenamento de dados. O resultado é um sistema de arquivos com um designer aperfeiçoado, melhor performance, confiável e com muitos recursos.
Recursos do Ext4
Compatibilidade
Um sistema de arquivos Ext3 existente, pode ser migrado para Ext4 com um procedimento fácil, onde consiste a execução de um casal de comandos em modo “read-only” (descrito na próxima seção). Por meio disto você melhora a performance, limites de armazenamentos e recursos do sistema de arquivos corrente, com ou sem a “reformatação” e/ou reinstalação do SO e softwares “environment”. Se você precisa das vantagens do Ext4 em um sistema em produção, você pode atualizar o sistema de arquivos. O processo é seguro é não há riscos para seus dados (obviamente, fazer backup de dados críticos é recomendado, pois você está atualizando seu sistema de arquivos). O Ext4 vai usar uma nova estrutura de dados somente em novos dados, a estrutura antiga continuará intocada, é será possível para leitura/escrita se for preciso. Desta forma, é claro, assim que uma vez convertido o sistema de arquivos para Ext4, você não vai poder voltar para o Ext3 novamente (embora há uma possibilidade, descrita na próxima seção, montando um sistema de arquivos Ext3 com Ext4 com ou sem o uso de um novo disco formatado, e você poderá montar com o Ext3 novamente, porém você irá perder todas as vantagens do Ext4).
Sistema de arquivos ou arquivos grandes
Atualmente, Ext3 suporta 16TB de tamanho máximo no sistema de arquivos, e 2TB de tamanho máximo de um arquivo. Ext4 adiciona 48-bit endereçados, obtendo assim 1EB de tamanho máximo de sistema de arquivos e 16TB de tamanho máximo de arquivos. 1 EB = 1,048,576 TB (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). Porque 48-bit e não 64-bit? Há algumas limitações daquele que pode precisar que seja fixado antes da construção do Ext4 enchendo a capacdade de 64-bit, no qual não tem como ser endereçado no Ext4. A estrutura de dados do Ext4 tem que ser desenhada mantendo em mente, um recurso de atualização para o Ext4 implementando completamente suporte a 64-bit até algum ponto. 1EB pode ser suficiente (realmente enquanto isso acontecer). (Note: o código para criar sistemas de arquivos grandes como 16TB não é estável nas versões do e2fsprogs).
Escabilidade de subdiretórios
Atualmente a possibilidade máxima de número de subdiretórios contendo um único diretório no Ext3 é 32.000. Ext4 quebra esse limite, e possibilita um número ilimitado de subdiretórios.
Extends
Os tradicionais sistemas de arquivos derivados do Unix como o Ext3, utilizam um esquema de mapeamento indireto de blocos para manter cada trilho do bloco usado correspondente no dado de um arquivo. Isto é ineficiente para arquivos grandes, especialmente um arquivo grande deletado e/ou operações “truncate”, porque o mapeamento mantém uma entrada para muitos blocos únicos, e grandes arquivos tem muitos blocos – > mapeamentos enormes, lentidão para o manuseio. Os sistemas de arquivos modernos usam uma abordagem diferente chamada “extends”. Um extends é basicamente um punhado de blocos físicos continuo. Isto pode ser basicamente definido: “Os dados no próximo bloco n”. Por exemplo, um arquivo de 100MB pode ser alocado em um único extends deste tamanho, em vez de precisar da criação de um mapeamento indireto para 25600 blocos ( 4KB por bloco). Arquivos grandes são divididos em diversos extends. Extends melhora a performance e também ajuda a reduzir a fragmentação, uma vez que incentiva o continuo “layouts” do disco.
Alocação multiblock
Quando o EXT3 precisa de nova escrita de dados no disco, há um alocador de blocos que decide quais blocos livres deverá ser usado para a escrita do dado. Mas o alocador de blocos do Ext3 somente alocar um bloco (4KB) em um momento. Esta forma que o sistema precisa para escrever 100MB de dados mencionado anteriormente em outro ponto, será necessário para chamar o alocador de blocos 25600 vezes (isto simplesmente para 100MB!). Não só isto é ineficiente, como também não permite que o bloco de alocação utilize a política de alocação porque ele não sabe como o total de muitos dados deve ter a alocação iniciada, ele apenas conhece sobre um simples bloco. Ext4 usa “multiblock allocator” (mballoc), no qual, aloca muitos blocos em uma simples chamada, em vez de um simples bloco por chamada, evitando um monte de overhead. Isto melhora a performance, e é especialmente útil com “alocação atrasada” e extends. Este novo recurso não afeta o formato do disco. Também, note que o Ext4 blocos/inode tem outras melhorias no alocador, descrição e detalhes neste documento (http://ols.fedoraproject.org/OLS/Reprints-2008/kumar-reprint.pdf).
Atraso na alocação
Atraso na alocação (http://en.wikipedia.org/wiki/Allocate-on-flush) é um recurso de performance (isto não muda o formato do disco) encontrado em poucos sistemas de arquivos modernos, tais como o XFS, ZFS, btrfs ou Reiser 4, que constitui em um atraso na alocação de blocos tanto quando possível, contrário aos tradicionais sistemas de arquivos (tais como o Ext3, Reiser3, etc) fazem: alocando os blocos com a maior brevidade possível. Por exemplo, em um processo de escrita, o código do sistema de arquivos irá atribuir imediatamente os blocos quando os dados forem coletados – mesmo se os dados não estiverem sendo escritos agora para o disco, eles vão ser mantidos em cache durante um tempo. Esta abordagem tem algumas desvantagens.Por exemplo, quando um processo esta escrevendo continuamente em um arquivo, crescente, sucessivamente sendo escritos atribuindo blocos para os dados, mas ele não sabe se o arquivo se manterá crescente. Atrasando a alocação, por outro lado, não afetaria os blocos imediatamente quando o processo de escrita, sim, ela atrasa a alocação dos blocos, enquanto o arquivo é mantido em cache, até que ele esteja realmente indo para escrito no disco. Isto da ao bloco de alocação a capacidade de alocar em situações em que sistemas antigos não poderia. Atraso na alocação trabalha muito bem com as duas características anteriormente mencionadas, extents e alocação multiblock, porque, em muitos casos um trabalho em que o arquivo é gravado para o último disco que será atribuído em blocos extends, cuja alocação é feita com o mballoc. O desempenho é muito melhor, e a fragmentação é muito melhorada em alguns workloads.
fsck rápido
Fsck é uma operação muito lenta, especialmente o primeiro passo: checagem de todos os inodes em um sistema de arquivos. No Ext4, até o fim de cada grupo da tabela de inode estará armazenado uma lista de inodes inutilizados ( com checksum, por segurança), assim o fsck não irá checar estes inodes. O resultado final é que o tempo do fsck melhorou de 2 a 20 vezes, dependendo do número usado de inodes (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Deve-se notar que é o fsck, e não o Ext4, que irá montar a lista de inodes inutilizados. Isso significa que você deve executar o fsck para obter a lista de inodes inutilizados construída, e só na próxima execução do fsck será mais rápida (você precisa passar o fsck, a fim de converter um ext3 filesystem para Ext4 de qualquer forma). Há também uma característica que ajuda a acelerar o fsck – “flexible block groups” – que também acelera as operações em arquivos.
Journal checksumming
O Journal é mais utilizado na parte do disco, construindo os blocos mais propensos a falhas de hardware. A recuperação de um journal corrompido pode levar a uma corrupção massiva. Ext4 checksums do dados de journal verificando se os blocos de journal estão falhando ou corrompendo. Mas “journal checksumming” tem um bonus: ele permite para conversão e gravação em duas-fases, sendo no Ext3 o journal em única fase, acelerando a operação no sistema de arquivos para mais de 20% em alguns casos – assim a reabilitação e a performance são melhoradas ao mesmo tempo (Nota: parte dos novos recursos e melhorias de performance, e “asyncrhonous logging”, está desativada por padrão e será ativada em versões futuras).
Desfragmentação Online
(Este recurso não está disponível no 2.6.28, mas provavelmente estará disponível na próxima versão). Enquanto o atraso de alocação, extends e alocação multiblock ajuda a reduzir a fragmentação, em uso de sistemas de arquivos que podem estar fragmentados. Por exemplo: Você escreveu três arquivos em um diretório e “contigually” no disco. Algum dia você irá atualizar o arquivo médio, mas o arquivo atualizado cresceu um pouco, portanto não há espaço para ele. Você não tem nenhuma opção, além do excesso fragmentado de dados para outro local do disco, o que irá causar uma procura, ou alocar a atualização do arquivo “contigually” em outro lugar, longe dos dois outros arquivos, resultando em uma procura se uma aplicação necessitar ler todos os arquivos no diretório (digamos, um gerenciador de arquivos fazendo thumbs em um diretório cheio de imagens). Além disso, o sistema de arquivos só pode preocupar-se com certos tipos de fragmentação, não é possível saber, por exemplo, que deve manter todos os arquivos relacionados com o “boot-related”, porque não sabe quais arquivos estão relacionados com a inicialização. Para resolver este problema, Ext4 apoiará online fragmentação, e há uma ferramenta, e4defrag, que pode desfragmentar arquivos individuais ou todo o sistema de arquivos.
Recursos relacionados aos Inodes
Aumento de inodes, timestamps em nano segundos, rápida alocação extends, reserva de inodes…
* Aumento de inodes: Ext3 suporta a configuração de tamanho de inode ( pelo parâmetro -l do mkfs), mas o tamanho padrão de inode é 128 bytes. Ext4 tem como padrão 256 bytes. Isto é necessário para acomodar algumas características extras (como o timestamp em nano segundos ou versonamento de inodes), e o espaço restante do inode será utilizado para armazenar atributos extends suficientemente pequenos para caber nesse espaço. Isto facilitará o acesso aos atributos com maior agilidade, e melhora no desempenho das aplicações que usem alocação extend por um fator de 3-7 vezes.
* A reserva de inode consiste em alocar vários inodes quando um diretório é criado, esperando que eles sejam utilizados no futuro. Melhorando a performance, porque quando novos arquivos forem criados neste diretório, eles serão capazes de utilizar os inodes reservados. Portanto a criação de um arquivo, como também a ação de apagar o mesmo, será mais eficiente.
* timestamps em nano segundos significa que áreas com “tempo modificado” sejam capazes de usar resoluções em nano segundos em vez de segundo como no Ext3.
Persistência na pré-alocação
Este recurso, disponível no Ext3 e em versões anteriores do kernel, e emulado para glibc em sistemas de arquivos sem suporte a isto, permitindo que aplicação pré-alocarem espaço em disco: As aplicações chamam o sistema de arquivos para pré-alocar o espaço, e o sistema de arquivos aloca a quantida necessária de blocos e estrutura de dados, mas não há dados sobre o assunto até que a aplicação realmente precisa para escrever os dados no futuro. Isto é o que faz aplicações P2P quando “pré-aloca” o espaço necessário para uma transferência que irá durar horas ou dias, mas muito mais eficiente implementado por um sistema de arquivos do que por uma API genérica. Isto tem varios usos: em primeiro lugar, para evitar aplicações (como aplicativos P2P) faze-lo propriamente e ineficientemente, mediante o preenchimento de um arquivo com zeros. Segundo, para melhoria da fragmentação,
uma vez que os blocos serão alocados em um tempo, e continuamente se possível. Terceiro, para assegurar que os pedidos tenham sempre o mesmo espaço solitado para a necessidade, o que é importante para aplicações RT-ish, pois sem a pré-alocação o sistema de arquivos poderá ficar cheio no meio de uma operação importante. Este recurso estará disponível via libc posix_fallocate() interface.
Padrões de barreiras
Este é uma opção que melhora a integridade de um sistema de arquivos ao custo de cerca de desempenho (você pode desabilitar isso com “mount -o barrier=0″, recomendado que seja testado com um benchmarking). Neste artigo da LWN (http://lwn.net/Articles/283161/): “O código do sistema de arquivos tem, antes de escrever [journaling] e gravando o registro, ter certeza absoluta de todas as informações de operações para a criação do journaling. Apenas escrever, no bom sentido, é insuficiente; os dispositivos atuais mantêm grandes chache interno e reordenam operações para melhor performance. Portanto, os sistemas de arquivos devem explicitamente instruir o disco para obter todos os dados do journaling antes da escrita e gravação das alterações; se a gravação dos registros forem escritas em primeiro lugar, o journaling pode ser corrompido. No kernel, os subsistemas de blocos de I/O torna essa capacidade disponível através de uso de barreiras, na sua essência, uma barreira impede a escrita de qualquer bloco após a barreira até que todos os blocos escritos antes da barreira sejam gravados na mídia. Ao utilizar barreiras, o sistema de arquivos pode ter certeza que sua estrutura em disco permaneçam consistentes em todo o momento”.
Como usar o Ext4
Esta é a primeira versão estável do Ext4, assim, mesmo que todo o lançamento e desenvolvimento deste sistema de arquivos fosse lento, e atrasando muito para garantir que o mesmo nível de estabilidade que você esperaria da implementação atual do Ext3, sendo aplicadas a regras de qualquer software “.0″.
Uma coisa muito importante para se manter em mente, é que não há suporte Ext4 no GRUB. Bem, isso não é exatamente verdade: há suporte para o grub, mas as versões atuais do grub, na maioria das distribuições, não tem este suporte. Há suporte no grub2 no branch de desenvolvimento, mas só a partir deste commit (http://svn.savannah.gnu.org/viewvc?view=rev&root=grub&revision=1699). Há pacotes disponíveis do grub2 para Ubuntu, distribuições baseadas no Debian e distribuições com o pacote grub-pc. No branch 0.9x, há suporte não oficial, mas há um projeto no Google SoC (http://code.google.com/p/grub4ext4/) com suporte a isto, e no google finds patches (http://lists.openwall.net/linux-ext4/2008/11/19/8). Então, você escolhe. As próximas distribuições baseadas no Kernel 2.6.28, provavelmente, terá suporte de uma forma ou de outra. A opção segura é manter seu diretório /boot em uma partição formatada com Ext3.
Você também precisa realizar a atualização da ferramenta e2fsprogrs, é claro, a última versão estável – 1.41.3 – é recomendada.
Mudar para Ext4 é muito fácil. Há 3 formas diferentes para fazer essa mudança:
Criando um novo sistema de arquivos do zero
É muito fácil, recomendado para novas instalações. Basta fazer a atualização do seu pacote e2fsprogs para o Ext4. E criar um sistema de arquivos com mkfs.ext4.
Migrando um sistema de arquivos com Ext3 para Ext4
Você vai precisar usar as ferramentas tun2fs e o fsck no sistema de arquivos, sendo que o sistema de arquivos deve estar desmontado, execute:
tune2fs -O extents,uninit_bg,dir_index /dev/seu_sistema_de_arquivos
Após rodar esse comando você DEVE rodar o fsck. Se você não fazer isso, o Ext4 NÃO PODERÁ MONTAR seu sistema de arquivos. Executar o fsck é necessário para retornar um sistema de arquivos consistente. Ele irá informar se encontrou checksum com erros na descrição de grupos – e espera – exatamente o que precisa ser reconstruído para montar o Ext4, não se surpreenda com ele. Cada vez que ele encontrar um erro irá perguntar o que fazer, sempre digo sim (YES). Se você não quiser ser questionado, passe o parâmetro “-p” ao executar o comando fsck, que significa “reparação automática”.
fsck -pf /dev/seu_sistema_de_arquivos
Há um outro aspecto que deve ser mencionado. Todos os arquivos existentes irão continuar utilizando o mapeamento indireto para mapear todos os blocos de dados. A ferramenta “online defrag” será capaz de migrar cada um destes arquivos para o formato extends (usando um ioctl que diz para o sistema de arquivos para reescrever o arquivo no formato extends; enquanto você estiver usando o sistema de arquivos normalmente).
Mountando um sistema Ext3 existente com Ext4 sem alterar o formato
Você pode montar um sistema de arquivos Ext3 com Ext4 mas sem utilizar recursos que altere o formato do disco. Isso significa que você poderá montar um sistema de arquivos com Ext3 novamente. Você pode montar um sistema de arquivos com Ext3 pelo comando “mount -t ext4 /dev/sua_partição /mnt”. Fazendo isto, sem ter feito o processo de conversão descrito anteriormente, forçando o Ext4 a não utilizar os recursos de mudança deste formato de disco, tais como extends, que irá utilizar as funcionalidades que não altera o formato de disco, tais como mballoc ou atraso de alocação. Você será capaz de montar seu sistema de arquivos Ext3 novamente. Mas, obviamente, você perderá todas as vantagens e características do uso do Ext4…
Fonte: http://andrem.wordpress.com/2008/12/26/ext4/
