1. Introdução
Ext4 é a evolução do sistema de arquivos Linux mais usado, o Ext3. De muitas maneiras, Ext4 é uma profunda melhoria em relação ao Ext3 do que o Ext3 foi em relação ao Ext2. A principal característica do Ext3 foi a adição de journaling para Ext2, mas o Ext4 modifica as estruturas de dados importantes do sistema de arquivos como os destinados a armazenar os dados dos arquivos. O resultado é um sistema de arquivos com um design melhorado, melhor performance, confiabilidade e características.
2. Características EXT4
2.1. Compatibilidade
Qualquer ext3 existente pode ser migrado para Ext4 com um procedimento simples, que consiste na execução de um par de comandos em modo só de leitura (descrito na próxima seção). Isso significa que você pode melhorar o desempenho, limites de armazenamento e as características de seu sistema de arquivos atual sem reformatação e / ou reinstalar o sistema operacional e ambiente de software. Se você precisar das vantagens do Ext4 em um sistema de produção, você pode atualizar o sistema de arquivos. O procedimento é seguro e não arrisca seus dados (obviamente, backup de dados críticos é recomendado, mesmo se você não está atualizando seu sistema). Ext4 irá utilizar as estruturas de dados novos apenas em dados novos, as antigas estruturas irão permanecer intocadas e será possível a leitura e modificação quando necessário. Isto significa que, naturalmente, depois de converter seu sistema de arquivos para Ext4 você não será capaz de voltar para Ext3 novamente (embora haja uma possibilidade, descrita na próxima seção, de montar um sistema de arquivos Ext3 com Ext4 sem utilizar o novo formato de disco e você será capaz de montá-lo com Ext3 novamente, mas você perde muitas das vantagens de Ext4
2.2. Maior sistema de arquivos / Maiores tamanhos de arquivo
Atualmente, o Ext3 suporta 16 TB de tamanho máximo de sistema de arquivos, e 2 TB de tamanho máximo de arquivo. Ext4 acrescenta blocos de 48-bits de resolução, de modo que terá 1 EB de tamanho máximo de sistema de arquivos e 16 TB de tamanho máximo de arquivo. EB 1 = 1.048.576 TB (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). Por que 48-bit e não 64-bit ? Existem algumas limitações que precisam ser corrigidos antes de fazer Ext4 totalmente 64-bits, que não foram ainda abordadas no Ext4. As estruturas de dados Ext4 foram concebidos tendo isto em mente, assim, uma futura atualização do Ext4 vai implementar suporte completo 64-bit algum ponto. 1 EB será o suficiente (na verdade:)) até que isso aconteça. (Nota: A implementação para criar sistemas de arquivos maiores do que a 16 TB , no momento da escrita deste artigo, não está em nenhuma versão estável do e2fsprogs. Vai estar em lançamentos futuros.)
2.3. Escalabilidade de Sub diretórios
Neste momento, o número máximo possível de sub-diretórios contidos em um único diretório em Ext3 é 32000. Ext4 quebra este limite e permite um número ilimitado de sub-diretórios.
2.4. Extensões
Os sistemas de arquivos tradicionalmente derivados do Unix, como Ext3, usam um esquema de mapeamento indireto de blocos para acompanhar cada um dos blocos utilizados correspondentes aos dados de um arquivo. Isto é ineficiente para arquivos muito grandes, especialmente em operações de apagar e truncar em grandes arquivos, porque o mapeamento mantém uma entrada para cada bloco único, e grandes arquivos têm muitos blocos, tornando o mapeamentos enorme, lento de manusear. Sistemas de arquivos modernos usam uma abordagem diferente chamado de "extensões". Uma extensão é basicamente um conjunto de blocos físicos contíguos . Ele basicamente diz: "Os dados estão nos próximos n blocos ". Por exemplo, um arquivo de 100 MB pode ser alocado em uma única extensão desse tamanho, em vez da necessidade de criar o mapeamento indireto de 25600 blocos (4 KB por bloco). Arquivos grandes são divididos em diversas extensões. Extensões melhoram o desempenho e também ajudarm a reduzir a fragmentação do disco, uma vez que uma extensão incentiva esquemas contínuos de ocupação do disco.
2.5. Alocação Multiblocos
Quando Ext3 precisa gravar novos dados no disco, há um alocador de blocos que decide que blocos livres serão usados para gravar os dados. Mas o alocador de blocos Ext3 apenas aloca um bloco (4KB) de cada vez. Isso significa que, se o sistema precisa escrever 100 MB de dados mencionado no ponto anterior, será necessário chamar o alocador de blocos 25600 vezes (e foi um arquivo de apenas 100 MB!). Não só isso é ineficiente, como também não permite que o alocador de blocos otimize a política de atribuição, porque ele não sabe o número total de dados que estão sendo alocados, ele só conhece um único bloco. Ext4 usa um alocador multiblocos "(mballoc), que atribui muitos blocos em uma única chamada, em vez de um bloco único por chamada, evitando muita sobrecarga. Isso melhora o desempenho, e é particularmente útil com delay de alocação e extensões. Esse recurso não afeta o formato de disco. Além disso, observe que o alocador bloco/ inode do Ext4 tem outras melhorias, descritas em detalhe neste trabalho.
2.6. Alocação atrasada
Alocação atrasada é uma característica de desempenho (isso não muda o formato de disco) encontrada em alguns sistemas de arquivos modernos, como XFS, ZFS, btrfs ou Reiser 4, e consiste em atrasar a alocação dos blocos, tanto quanto possível, ao contrário do que tradicionalmente, sistemas de arquivos (como o ext3, reiser3, etc) fazer: repartir os blocos o mais depressa possível. Por exemplo, se um processo de escrever () s, o código do sistema alocará imediatamente os blocos onde os dados serão colocados - mesmo que os dados não está sendo escrito agora para o disco e vai ser mantida no cache para alguns tempo. Esta abordagem tem desvantagens. Por exemplo, quando um processo está escrevendo continuamente para um arquivo que cresce, sucessivas write () s alocar blocos de dados, mas não sei se o arquivo vai continuar crescendo. Alocações atrasadas, por outro lado, não vão alocar os blocos imediatamente quando o processo de escrever () s, em vez disso, os atrasos da alocação dos blocos enquanto o arquivo é mantido no cache, até que seja realmente gravado no disco . Isto dá ao alocador de blocos a oportunidade de otimizar a alocação em situações em que o sistema antigo não podia. Alocação atrasada joga muito bem com as duas características mencionadas anteriormente, extensões e alocação multiblocos, pois em diversas cargas de trabalho quando o arquivo é finalmente gravado, o disco será alocado em extensões de múltiplos blocos cuja alocação é feita com o alocador mballoc. O desempenho é muito melhor, e a fragmentação é muito melhor em algumas cargas de trabalho.
2.7. Fsck Rápido
Fsck é uma operação muito lenta, especialmente o primeiro passo: verificação de todos os inodes no sistema de arquivos. Em Ext4, no final da tabela de inode de cada grupo será armazenado uma lista de inodes utilizados (com uma verificação, por segurança), assim que o fsck não irá checar os inodes. O resultado é que o tempo total do fsck melhora de 2 a 20 vezes, dependendo do número de inodes usados (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Deve ser notado que é o fsck, e não Ext4, que vai construir a lista de inodes utilizados. Isto significa que você deve executar o fsck para obter a lista de inodes utilizados construída, e só executar o fsck na próxima vez será mais rápido(você precisa passar um fsck para converter um sistema de arquivos ext3 para ext4 de toda maneira). Há também uma característica que ajuda a aumentar a velocidade do fsck - "grupos de blocos flexíveis" - que também acelera as operações de arquivos.
2.8. Checksum do Journal
O journal é a parte mais utilizada do disco, fazendo com que os blocos que fazem parte do mesmo mais propensos a falhas de hardware. E a recuperação de um journal danificado pode levar à corrupção massiva dos dados do disco. Ext4 faz somas de segurança (checksum) dos dados do journal para saber se os blocos estão com falhas ou corrompidos. Mas checksumming do journal tem um bônus: ele permite converter as duas fases do sistema de journaling do Ext3 para uma única fase, acelerando o funcionamento do sistema de arquivos em até 20% em alguns casos - assim a confiabilidade e o desempenho são aprimorados, ao mesmo tempo. (Nota: a parte do recurso que melhora o desempenho, o log assíncrono, é desligado por padrão agora, e será ativado em versões futuras, quando melhorar a confiabilidade)
2.9. "No Journal mode"
Journaling garante a integridade do sistema de arquivos, mantendo um log das mudanças em curso no disco. No entanto, é sabido que ele causa uma pequena sobrecarga. Algumas pessoas com necessidades especiais e cargas de trabalho diferenciadas, o sistema de arquivos pode ser executado sem um journal e sem as vantagens relativas à sua integridade. Em Ext4 o recurso de journaling pode ser desativado, o que proporciona uma melhora de desempenho pequeno.
2.10. A desfragmentação online
(Este recurso está sendo desenvolvido e será incluído em versões futuras).
Embora a alocação atrasada, extensões e alocação de múltiblocos ajudem a reduzir a fragmentação, com o uso, sistemas de arquivos podem fragmentar ainda. Para resolver este problema, o Ext4 suportará desfragmentação on line, e há uma ferramenta (e4defrag) que pode desfragmentar arquivos individuais ou todo o sistema de arquivos.
2.11. recursos relacionados a Inodes
Inodes maiores, timestamps de nanossegundos, atributos extendidos rápidos , reserva de inodes ...
* Inodes maiores: Ext3 suporta tamanhos configuráveis de inodes (através do parâmetro mkfs-I), mas o tamanho do inode padrão é 128 bytes. Ext4 mudará o padrão para 256 bytes. Isso é necessário para acomodar alguns campos extras (como timestamps de nanossegundos ou versões diferentes de inode), e o espaço restante do inode será utilizado para armazenar atributos estendidos que são pequenos o suficiente para caber nesse espaço. Isso fará com que o acesso a esses atributos seja muito mais rápido, e melhora o desempenho das aplicações que utilizam atributos estendidos por um fator de 3-7 vezes.
* Timestamps de Nanossegundos significa que os campos dos inodes relativos à hora de gravação/modificação , serão capazes de usar resolução de nanossegundos em vez da resolução de segundos do Ext3.
* Reserva de Inodes consiste em reservar vários inodes quando um diretório é criado, aguardando quando serão utilizados no futuro. Isso melhora o desempenho, porque quando novos arquivos são criados no diretório eles serão capazes de usar os inodes já reservados, agilizando a criação (e consequentemente) a deleção de arquivos.
2.12. Pré-alocação persistente
Esse recurso, disponível no Ext3 nas versões mais recentes do kernel, e emulado por glibc em sistemas de arquivos que não suportam, permite aos aplicativos pré-alocar espaço em disco: Aplicações dizem ao sistema de arquivos para pré-alocar o espaço, e o sistema de arquivos pré-aloca os blocos necessários e estruturas de dados, mas não há dados para preenchê-los até que a aplicação realmente precise gravar os dados. Isto é o que fazem aplicações P2P à sua maneira: o espaço necessário para uma transferência que irá durar horas ou dias já está reservado para o arquivo. Mas, com o EXT4, será implementado com muito mais eficiência pelo sistema de arquivos e com uma API genérica. Este tem várias utilidades: em primeiro lugar, para evitar aplicações (como aplicativos P2P) de fazer a mesma coisa de forma ineficaz, preenchendo um arquivo com zeros. Em segundo lugar, para melhorar a fragmentação, uma vez que os blocos serão atribuídos ao mesmo tempo, da melhor forma contígua possível. Terceiro, para garantir que as aplicações sempre terão o espaço em disco que realmente vão precisar para os seus arquivos, o que é importante para as aplicações "real time", já que, sem a pré-alocação, o sistema de arquivos poderia ficar cheio no meio de uma operação importante de escrita.
2,13. Barreiras por padrão
Esta é uma opção que melhora a integridade do sistema de arquivos ao custo de algum desempenho (você pode desabilitá-lo com ""mount -o barrier=0", recomendou a tentar se você for fazer benchmarking). A partir deste artigo LWN: O controle do filesystem deve, antes de escrever o registro do journaling, se certificar que todas as transações que ocorreram no disco estão no journal.
Apenas fazendo a escrita do journaling na ordem correta não é suficiente; Os discos atuais tem caches internos grandes e vão reordenar as operações para um melhor desempenho. Assim, o controle do sistema de arquivos deve instruir explicitamente o disco a descarregar todos os dados sobre o journal antes de gravar o registro do journal. Se o regsitro do journal for gravado antes, o journal pode ser corrompido.
O kernel disponibiliza essa característica através do uso de barreiras. Em essência, uma barreira não permite que o journal seja escrito antes de que todas as operações que ele relata sejam escritas antes.
Usando barreiras, o sistema de arquivos aumenta consideravelmente a sua confiabilidade.
Fonte: http://kernelnewbies.org/Ext4
Nenhum comentário:
Postar um comentário