A evolução dos sistemas de arquivos:Do Ext ao Ext4

● Ext

Inicialmente, Linus Torvalds adaptou o sistema de arquivos do MINIX, de Andrew Tanembaum, para o Linux. Porém, por possuir várias limitações, como tamanho limite para o nome do arquivo (14 caracteres) e para o tamanho de um arquivo ou uma partição (64 MB), acabou sendo substituído pelo Ext2, desenvolvido em 1993 por Rémy Card.

● Ext2

O 2nd Extended File System, Ext2, foi projetado para corrigir as deficiências de seu antecessor, que era simplismente uma adaptação de outro sistema de arquivos, e procurou seguir a semântica do UNIX.

● Melhoras em relação ao Ext:

1. O tamanho limite para o nome de um arquivo foi aumentado para 255 caracteres;

2. O tamanho máximo de um arquivo passa de 64MB para uma faixa entre 16GB e 2TB (o tamanho varia de acordo com o tamanho dos blocos, que é variável);

3. O tamanho máximo de uma partição passa a ser entre 2 e 32 TB.

● Bloco

É a menor unidade de alocação do Ext2. Constitui vários setores (cada um possui 512 bytes) e pode ter tamanho de 1, 2 ou até 4KB.

● Super-bloco

É a estrutura básica do Ext2. Ocupa 1024 bytes e inicia no terceiro setor da partição pois os primeiros 1024 bytes de cada partição são sempre reservados para o boot.

O quadro a seguir mostra todos os atributos existentes no super-bloco:

● I-nodes

Um arquivo é descrito por um i-node. O i-node é uma estrutura de dados com tamanho padrão de 128 bytes(o tamanho é definido na formatação).

A tabela seguinte mostra seus atributos:

● Grupos de blocos

Cada partição é dividida em grupos de blocos de mesmo tamanho. Com um tamanho de bloco de 4 KB, um grupo contém 32768 blocos.

Cada grupo de blocos possui uma tabela de descritores que endereçam os mapas de bits dos blocos e dos i-nodes e a tabela de i-nodes. O primeiro grupo contém o superbloco, que possui cópia em alguns outros grupos. No mapa de bits de blocos, cada byte mapeia 8 blocos (um por bit). O bit menos significativo identifica o bloco de menor número. O mapa de bits de i-nodes é análogo.

Os grupos de blocos são representados pela seguinte estrutura:

● Mapa de bits de blocos

Em cada grupo de blocos, um bloco é alocado para indicar se os restantes estão ocupados ou livres. Quando o bloco possui tamanho 4 KB, é possível mostrar 32768 blocos (4096 * 8). Se está alocado, é marcado com o bit '1', e caso contrário, com o bit '0'.

● Mapa de i-nodes

De forma análoga ao mapa de bits de blocos, um bloco é utilizado para indicar a alocação dos i-nodes. Geralmente o bloco não é totalmente utilizado pois o número de i-nodes é menor que o número de blocos.

● Tabela de i-nodes

A tabela de i-nodes é formada por blocos consecutivos após os mapas de bits. Cada entrada na tabela é um i-node. Portanto, para um bloco de tamanho 4 KB, é possível conter até 32 i-nodes.

● Alocação de blocos

Quando é feita a operação de escrita em um arquivo, o Ext2 tenta sempre que possível alocar blocos de dados no mesmo grupo de blocos que contém o i-node. Este comportamento reduz o movimento da cabeça de leitura-gravação da unidade de disco.

Em um sistema de arquivos podemos encontrar dois tipos de fragmentação: A fragmentação interna, que ocorre quando o tamanho do arquivo não é múltiplo do tamanho do bloco, ocorrendo uma perda de espaço no último bloco; fragmentação externa, que ocorre quando o arquivo possui blocos alocados não contiguamente, prejudicando seu desempenho.

Para a fragmentação interna, a solução é diminuir o tamanho padrão do bloco. Porém, ao fazermos isto, possuiremos um número maior de blocos para serem gerenciados, prejudicando o desempenho. Outra solução é aplicar o tail packing, ou

seja, utilizar fragmentos de vários arquivos, menores que um bloco, em um bloco só. Porém, o Ext2 não implementa esta funcionalidade.

Para a fragmentação externa, o Ext2 reserva até 8 blocos quando um arquivo é aberto para gravação. Esses blocos reservados, quando possível, são adjacentes ao último bloco utilizado pelo arquivo.

● Ext3

O Ext3 (ou third extended filesystem) é baseado em journaling, que é comumente usado pelo kernel do Linux. Sua maior vantagem sobre o antigo Ext2 é justamente o uso dojournaling, que aumenta a confiabilidade e elimina a necessidade de checar o sistemade arquivos depois de um desligamento inesperado do sistema.

● Vantagens

Apesar de sua performance (velocidade) ser menos atrativa em comparação comoutros sistema de arquivos Linux como o JFS, ReiserFS e o XFS, o Ext3 tem umaimportante vantagem, que é a de ser possível um upgrade direto do ext2 sem anecessidade de backup e restauração de dados.

Em relação ao Ext2, possui as seguintes melhorias:

1. Journaling;2. Crescimento do sistema de arquivos de forma online;3. Indexação por H-tree para diretórios com muitos arquivos. Uma H-tree é uma

versão especial de uma B-tree.

Sem estes elementos, qualquer sistema Ext3 se torna um Ext2 válido. Isto permitiuque ferramentas de manutenção e reparação de sistemas de arquivos Ext2 jábem testadas e maduras pudessem ser usadas para sistemas Ext3 sem grandesmodificações. Ambos usam o mesmo conjunto de ferramentas padrão, o e2fsprogs,que inclui um fsck. A estreita relação permite a conversão direta entre os sistemas, em ambas as direções (tanto Ext2 para Ext3, quanto o caminho inverso).

Enquanto que em algumas situações a falta de características de sistemas dearquivos “modernos”, como a alocação dinâmica de i-nodes, pode ser consideradauma desvantagem. Quando se trata de recuperação de dados o Ext3 tem umasignificativa vantagem sobre seus concorrentes. Os metadados do sistema ficam todos armazenados em localizações fixas e bem conhecidas, e há uma certa redundância inerente nas estruturas de dados que permitem que Ext2 e Ext3 sejam recuperáveis face a uma corrupção de dados significativa, onde sistemas baseados

em árvores de arquivos podem não ser.

● Journaling

Há três níveis de journaling no Ext3:

1. Journal (risco mais baixo): Tanto metadados quanto o conteúdo dos arquivos são escritos no journal antes de serem submetidos ao sistema de arquivos principal. Por o journal ser relativamente contínuo no disco, isto aumenta a performance em algumas circunstâncias. Em outros casos, a performance pode piorar, em razão de os dados serem escritos duas vezes (uma vez no journal, e outra para o parte principal do sistema de arquivos).

2. Ordenado (risco médio): Apenas os metadados são escritos no journal, e o conteúdo dos arquivos não, mas é garantido que este conteúdo seja escrito no disco antes que os metadados correspondentes sejam marcados como submetidos no journal. Isto é o padrão em muitas distribuições Linux. Se houver falta de energia ou kernel panic enquanto um arquivo está sendo escrito ou modificado, o journal vai mostrar que o novo arquivo não foi “submetido” , portanto ele será limpado pelo processo de cleanup (portanto arquivos novos e modificados têm o mesmo tratamento que no nível journal). No entanto, arquivos sendo sobrescritos podem ser corrompidos porque a versão original do arquivo não foi guardada. Isto permite que um arquivo fique em um estado entre “novo” e “velho”, sem informação suficiente para restaurar completamente nenhum dos dois estados (os novos dados nunca serão gravados totalmente no disco, e os velhos não estão guardados em lugam algum). Pior ainda, este estado intermediário pode misturar dados novos e velhos, porque a ordem da escrita é controlada pelo próprio hardware do disco.

3. Writeback (risco mais alto): Somente metadados são escritos no journal; o conteúdo dos arquivos não. O conteúdo pode ser escrito antes ou depois que o journal é atualizado. Como consequência, arquivos modificados logo antes de uma pane podem ser corrompidos. Por exemplo, um arquivo com dados sendo anexados pode ser marcado no journal como sendo maior do que ele realmente é, causando inconsistências. Versões antigas de arquivos podem aparecer inesperadamente depois de uma recuperação do journal. A falta de sincronização entre dados e journal é rápida em muitos casos.

● Desvantagens

1. Funcionalidade: pelo Ext3 primar por ser retroativamente compatível com o antigo ext2, ele procura ser parecido com este. Por causa disto, muitas características presentes em sistemas mais recentes faltam nele, como extents, alocação dinâmica de inodes, e subalocação de blocos. Há um limite de 31998 subdiretórios por diretórios, vindo do fato do limite de 32.000 links por i-node.

O Ext3, assim como muitos sistemas de arquivos correntes de Linux, não pode ser checado por fsck enquanto o sistema está montado. Tentando-se fazer isso pode causar detecção de erros em dados modificados que ainda não foram escritos no disco, e o arquivo pode ser corrompido numa tentativa de “consertar” estes erros.

2. Desfragmentação: Não há uma ferramenta de desfragmentação online que funcione em um nível do sistema de arquivos. Existe um desfragmentador de Ext2 offline, o e2defrag, mas é necessário que o sistema Ext3 seja convertido para ext2 anteriormente. Entretanto, dependendo dos bits de funcionalidade ativados no filesystem, o e2defrag pode vir a destruir dados, pois não sabe como tratar muitas das novas características do Ext3. Há ferramentas de desfragmentação em userspace como o Shake e o Defrag. O Shake aloca espaço para um arquivo inteiro como uma única operação, o que geralmente faz com que o alocador encontre um espaço de disco contíguo, e também tenta gravar arquivos utilizados ao mesmo tempo de uma forma que fiquem próximos entre si. O Defrag sobrescreve um arquivo sobre ele mesmo. Contudo, ambos somente funcionam caso o sistema de arquivos esteja relativamente vazio. Uma ferramenta de desfragmentação verdadeira para o Ext3 não existe. Neste aspecto, há uma observação no Guia do Administrador de Sistemas Linux em que diz: “Sistemas de arquivos Linux modernos mantém a fragmentação em um nível mínimo ao deixar todos os blocos de um arquivo dispostos de forma próxima, ainda que não seja possível o armazenamento em setores consecutivos. Alguns filesystems, como o Ext3, efetivamente alocam os blocos livres que estão mais próximos dos outros blocos do arquivo. Logo, não é necessário preocupar-se com fragmentação em um sistema Linux”. Ainda que o Ext3 seja mais resistente à fragmentação que o FAT (File Allocation Table), é possível que ocorra fragmentação com o tempo ou com o uso de padrões de escrita específicos, como na gravação de arquivos grandes de forma lenta.

3. Recuperação: Não há suporte para a recuperação de arquivos deletados. Ext3 ativamente deleta os arquivos eliminando seus inodes, por razões de segurança contra crashes. Por isso um ‘rm –rf ...’acidental pode causar perda permanente de dados. Há algumas ferramentas comerciais que tentam recuperar dados perdidos pela análise do journal, no entanto elas não garantem nada. Não há nenhuma chance de recuperação de arquivos após uma formatação de disco.

4. Compressão: O suporte à compressão de forma transparente é disponibilizado na forma de um patch não-oficial. Este patch é um port direto do e2compr, e ainda precisa ser melhor desenvolvido; a compilação e o boot ocorre sem problemas comos upstream kernels**, mas o journaling ainda não foi implementado. O patch atual chama-se e3compr.

5. Incapacidade de obter snapshots: Diferente de muitos sistemas de arquivos modernos, o Ext3 não tem suporte nativo aos snapshots – a habilidade de se capturar rapidamente o estado do sistema de arquivos em momentos arbitrários,

ao invés de depender nos snapshots em nível de volume que são menos eficientes em termos de espaço, fornecidos pelo LVM** do Linux. O sistema de arquivos Next3 é uma versão modificada do Ext3 que oferece suporte aos snapshots, que ainda retém a compatibilidade com o formato do disco do Ext3.

6. Ausência de checksum no journal: O Ext3 não realiza checksums ao escrever no journal. Se a flag barrier=1 não for passada na hora do mount (em /etc/fstab), e o hardware estiver fazendo o caching de uma escrita fora de ordem, há o risco de um corrompimento sério do sistema de arquivos durante um travamento. Considere o seguinte cenário: Se o disco rígido realizar as operações de escrita fora de ordem (pois os caches dos discos rígidos modernos são feitas em ordem para se amortizar a velocidade de escrita), é possível que um commit block de uma operação seja feito antes que outros blocos relevantes sejam escritos. Na eventualidade de uma interrupção no fornecimento de energia elétrica ou de um travamento irrecuperável antes dos outros blocos serem escritos, o sistema terá de ser reiniciado. Neste processo, o file system verificará o log como normal, e autorizará as operações com o commit block, incluindo aquela que foi marcada como tal. A escrita inacabada acima então procederá, utilizando porém dados do journal corrompido. O file system então irá acidentalmente sobrescrever dados normais com dados corrompidos ao conferir o journal. Existe um programa de teste disponível para acionar este comportamento problemático. Se checksums fossem utilizados, onde os blocos da transação supostamente valida fossem marcados com um checksum mútuo, o sistema de arquivos teria maiores informações e não tentaria reescrever os dados corrompidos no disco. O checksumming de journal foi adicionado ao Ext4. Sistemas de arquivos que passem pela interface de mapeamento de dispositivos (incluindo RAID via software e implementações do Logical Volume Manager) podem não suportar barreiras, e gerarão um alerta caso tal opção de mount seja utilizada. Há também alguns discos que não implementam propriamente a extensão de flushing do cache de escrita necessária para que as barreiras funcionem, o que causa um alerta similar. Nestas situações, em que as barreiras não têm suporte ou não são práticas, um ordenamento de escrita confiável é possível ao se desligar o cache de escrita do disco e usando também a opção de montagem data=journal. Desligar o cache de escrita do disco pode ser necessário mesmo quando as barreiras estão disponíveis. Aplicativos como bancos de dados esperam uma chamada ao fsync(), que fará o flush de escritas pendentes ao disco, e a implementação de barreira nem sempre limpa o cache de escrita do disco em resposta a tal chamada. Existe também o problema potencial com a implementação de barreira relacionada à manipulação de erros durante eventos como uma falha de disco.

● Ext4

O sucessor do Ext3 foi criado como uma série de extensões retrocompatíveis para remover os limites de armazenamento em 64 bits, e adicionar outras melhorias de performanc. Entretanto, alguns desenvolvedores do kernel do Linux mostraram-se contrários em aceitar extensões no Ext3 por razões de estabilidade, e propuseram criar um fork do código fonte do Ext3, renomeá-lo de Ext4, e fazer todo o desenvolvimento desta forma, sem afetar os atuais usuários do Ext3. Tal proposta foi aceita, e em 28 de junho de 2006, Theodore Ts'o, o mantenedor do Ext3 na época, anunciou o novo plano de desenvolvimento para o Ext4.

Uma versão preliminar do Ext4 foi incluída na versão 2.6.19 do kernel. Em 11 de outubro de 2008, os patches que determinavam que o Ext4 tornou-se stable code foi integrado aos repositórios do código fonte do Linux 2.6.28, denotando o fim da fase de desenvolvimento e conseqüente recomendação da adoção do Ext4. O kernel 2.6.28 contendo o Ext4 foi finalmente lançado no dia 25 de dezembro de 2008. Em 15 de janeiro de 2010, o Google anunciou que atualizaria sua infraestrutura de armazenamento de Ext2 para Ext4.

● Características

1. Sistema de arquivos para grandes capacidades: o Ext4 dá suporte para volumes de até 1 exabyte de arquivos de até 16 terabytes. O atual e2fsprogs consegue lidar com um sistema de arquivos de até 16TB, entretanto o suporte para discos maiores está em desenvolvimento.

2. Extents: foram introduzidos para substituir o tradicional esquema de mapeamento de blocos usado pelo Ext2 e Ext3. Um extent é um série de blocos físicos contíguos, melhorando a performance em arquivos grandes e reduzindo a fragmentação. Um único extent no Ext4 pode mapear até 128MB de espaço contíguo com um tamanho de bloco de 4KB. Pode haver até 4 extents armazenados em um único inode. Quando há mais que 4 extents para um arquivo, o restante dos extents são indexados em uma Htree (uma especialização da árvore B).

3. Retrocompatibilidade: o Ext4 é retrocompatível com o Ext3 e o Ext2, tornado possível a montagem de sistemas de arquivos Ext3 e Ext2 como Ext4. Isso melhorará ligeiramente a performance graças a algumas novas características do Ext4 que podem ser usadas com o Ext3 e o Ext2, como o novo algoritmo de alocação de blocos.O Ext3 é parcialmente compatível antecipadamente com o Ext4, ou seja, uma partição Ext4 pode ser montada como Ext3. Entretanto, se a tal partição utilizar extents, tal operação não será possível.

4. Pré-alocação persistente: o Ext4 permite a pré-alocação de espaço no disco para um arquivo. O método atual para realizar esta operação na maioria dos file systems é escrever um arquivo cheio de zeros para reservar aquele espaço quando o arquivo for criado. Isto não é mais necessário no Ext4, pois uma nova

chamada de sistema fallocate() foi adicionada ao kernel para uso pelos arquivos de sistema, incluindo o Ext4 e o XFS, que tem capacidade para realizar este tipo de operação. O espaço alocado para arquivos como estes é garantido e provavelmente será contíguo, o que pode ter aplicações em streaming de mídia e em banco de dados.

5. Alocação atrasada: o Ext4 utiliza uma técnica chamada allocate-on-flush, também chamada de delayed allocation (alocação atrasada), que consiste em atrasar a alocação de blocos até que os dados estejam prontos para serem escritos em disco, ao contrário de outros sistemas de arquivos, que podem alocar os blocos necessários antes disso. Verifica-se uma melhoria na performance e redução de fragmentação ao melhorar as decisões da alocação de blocos baseadas no tamanho real do arquivo.

6. Remoção do limite de 32.000 subdiretórios: no Ext3 o número de subdiretórios que um diretório pode conter está limitado em 32.000. Este limite foi aumentado para 64.000 no Ext4 e com a funcionalidade "dir_nlink" é possível ir além (embora a contagem de subdiretórios na pasta-pai congele). Para garantir a performance dada a possibilidade de diretórios muito maiores, índices da Htree são habilitados por padrão no Ext4. Esta característica foi implementada no kernel 2.6.23. A Htree também está disponível no Ext3 quando o dir_index é habilitado.

7. Journal checksumming: utiliza checksums no journal para melhorar a confiabilidade, já que o journal é um dos arquivos mais utilizados no disco. Esta funcionalidade tem um benefício colateral: evita-se uma espera de I/O durante o processo de journaling, melhorando ligeiramente a performance. A técnica de journal checksumming foi inspirada em um paper da Universidade de Wisconsin entitulada IRON File Systems (especificamente, seção 6, chamada "transaction checksums").

8. Checagem do sistema de arquivos mais rápida: no Ext4, grupos de blocos não-alocados e seções da tabela de inode são marcadas como tal. Isso permite que o e2fsck pule estes inteiramente em uma checagem, o que reduz enormemente o tempo que levaria para um file system do tamanho que o Ext4 foi projetado para suportar. Esta funcionalidade foi implementada na versão 2.6.24 do kernel.

O gráfico abaixo nos dá uma visão mais nítida disto.

9. Alocador multi-bloco: quando um arquivo está sofrendo uma operação de append, o Ext3 chama o alocador de blocos para cada bloco individualmente. Com múltiplos escritores concorrentes, os arquivos podem se tornar fragmentados facilmente. Com a alocação atrasada, entretanto, o Ext4 armazena uma quantidade grande de dados em um buffer, e então aloca um grupo de blocos em lote. Isso significa que o alocador tem mais informações sobre o que está sendo escrito e pode fazer escolhas melhores para alocar arquivos no disco de forma contígua. O alocador multiblocos é usado quando outra alocação atrasada é habilitada para um file system, ou quando arquivos são abertos no modo O_DIRECT (diretamente no dispositivo de I/O). Esta funcionalidade não afeta o formato do disco.

10.Timestamps melhorados: como os computadores tornam-se mais velozes em geral, e como o Linux tem sido utilizado com mais freqüência para aplicativos de missão crítica, a granularidade de timestamps baseados em segundos torna-se insuficiente. Para solucionar este problema, o Ext4 fornece timestamps medidos em nanosegundos. Além disso, 2 bits do campo expandindo do timestamp são adicionados aos bits mais significativos do campo de segundos para adiar o problema no ano 2038* por mais 204 anos.

* O problema do ano 2038 (conhecido também como o Bug do Milênio do Unix, Y2K38 em analogia ao problema do Y2k, ano 2000) pode causar a falha de alguns softwares de computadores antes ou no ano de 2038. O problema afeta todos os softwares

e sistemas que armazenam o horário do sistema como um inteiro de 32 bits com sinal, e interpretam este número como o número de segundos desde às 00:00:00 UTC na terça, dia 1º de janeiro de 1970. O maior tempo de representação possível desta forma é 03:14:07 UTC na terça, 19 de janeiro de 2038. Horários após este momento "fecharão o ciclo" e serão armazenados internamente como um número negativo após o overflow, onde estes sistemas interpretarão a data como 1901 ao invés de 2038. Isto muito provavelmente causará problemas para usuários destes sistemas dado ao resultado errôneo do cálculo.

Já que a maioria dos sistemas de 32 bits baseados em Unix armazenam e manipulam o tempo neste formato, este é denominado "tempo do Unix", e por este motivo o problema do ano 2038 é chamado de Bug do milênio do Unix. Entretanto, qualquer outro sistema operacional não-Unix que armazene e manipule o tempo desta mesma forma estará igualmente vulnerável.

O Ext4 também passa a dar suporte para date-created timestamps. Entretanto, assim como Theodore Ts'o aponta, enquanto é algo trivial adicionar um campo extra para a data de criação no inode (tecnicamente permitindo então o suporte a date-created timestamps no Ext4), é mais difícil modificar ou adicionar os system calls necessários, como stat() (que provavelmente necessitaria de uma nova versão), e várias bibliotecas dependem destas funções (como o glibc). Estas mudanças requeririam a coordenação de muitos projetos, portanto mesmo que os desenvolvedores do Ext4 implementem o suporte inicial para timestamps de data de criação, esta característica não ficará disponível aos usuários de programas por enquanto.

● Desvantagens

- Alocação atrasada e potencial perda de dados: devido ao fato da alocação atrasada modificar o comportamento em que programadores estavam acostumados no Ext3, esta característica traz algum risco adicional de perda de dados em casos onde o sistema trava ou tem seu suprimento de energia cortado antes que todos os dados tenham sido escritos em disco. Outros file systems do Linux como o XFS nunca ofereceram um comportamento similar ao do Ext3. Por isso, o Ext4 nas versões do kernel 2.6.30 e posteriores automaticamente detectam estes casos e revertem o funcionamento para o modo anterior de operação.

O cenário típico em que isso pode ocorrer é quando um programa tenta sobrescrever o conteúdo de um arquivo sem forçar a escrita ao disco via fsync. Há dois meios comuns de se sobrescrever o conteúdo de um arquivo em um sistema Unix:

open("file", O_TRUNC); write(fd, data); close(fd):Neste caso, um arquivo existente é truncado no momento de sua abertura (por causa da flag O_TRUNC), então dados novos são escritos. Já que a escrita pode levar algum

tempo, é possível que haja uma oportunidade em que conteúdo seja perdido mesmo com o Ext3, que no entanto seria pequeno. No entanto, como o Ext4 pode atrasar a alocação dos dados de arquivo por um período extenso, esta ocasião pode ocorrer com muito mais freqüência.

open("file.new"); write(fd, data); close(fd); rename("file.new", "file"):Um novo arquivo temporário ("file.new") é criado, no qual há o novo conteúdo. Então este novo arquivo é renomeado. A substituição de arquivos pela chamada rename é garantidamente atômica pelos padrões POSIX - ou seja, ou o arquivo antigo permanece intacto, ou é sobrescrito pelo novo. Pelo fato do modo padrão de journalling "ordenado" no Ext3 garantir que os dados de arquivo sejam escritos em disco antes dos metadados, esta técnica garante que ou o conteúdo antigo ou o novo persistirão em disco. A alocação atrasada do Ext4 quebra tal expectativa, pois a escrita do arquivo pode ser adiada por um longo tempo, e o rename é normalmente feito antes que o conteúdo do novo arquivo chegue ao disco.

Usar o fsync com mais freqüência para reduzir tal risco no Ext4 pode levar a quedas acentuadas de performance em sistemas Ext3 montados com a flag data=ordered (padrão na maioria das distribuições). Dado que ambos os file systems estarão em uso por algum tempo, cria-se complicações enormes para os desenvolvedores de aplicações para usuários finais. Por isso, o Ext4 no kernel 2.6.30 e posteriores detectam este tipo de ocorrência, e força os arquivos a serem alocados imediatamente. Pagando um custo pequeno em performance, provê-se uma semântica similar ao modo ordenado do ext3, e melhora-se a chance de que alguma das versões do arquivo sobreviverão ao travamento. Este novo comportamento é ativado por padrão, mas pode ser desativado com a opção de montagem "noauto_da_alloc".

Os novos patches passaram a fazer parte do kernel principal 2.6.30, mas várias distribuições optaram por fazer um backport para os kernels 2.6.28 ou 2.6.29. Como exemplo citamos o Ubuntu, que aplicou o patch no kernel na versão 9.04 ("Jaunty Jackalope").

● E2fsprogs

O e2fsprogs (chamado por vezes de e2fs programs) é um conjunto de utilitários para manutenção de sistemas de arquivos Ext2, Ext3 e Ext4. Já que estes file systems são normalmente o padrão para as distribuições Linux, é normalmente considerado como um software essencial.

Estão inclusos no e2fsprogs:

1. e2fsck, um programa fsck que checa e corrige inconsistências;2. mke2fs, usado para criar sistemas de arquivos Ext2, Ext3 e Ext4;3. resize2fs, que pode expandir e reduzir sistemas de arquivos Ext2, Ext3 e Ext4;4. tune2fs, usado para modificar parâmetros do sistema de arquivos;5. dumpe2fs, que imprime informações de superblocos e de grupos de blocos;6. debugfs, usado para visualizar manualmente ou modificar estruturas internas do

sistema de arquivos.

Referências:

-http://book.opensourceproject.org.cn/kernel/kernel3rd/opensource/0596005652/understandlk-chp-18-sect-2.html-http://en.wikipedia.org/wiki/Ext2-http://en.wikipedia.org/wiki/Ext3-http://en.wikipedia.org/wiki/Comparison_of_file_systems