O sistema de arquivos EXT3 é uma evolução do sistema de arquivos EXT2, que foi originalmente desenvolvido por Stephen Tweedie, Rémy Card e Theodore Ts'o e outros para a Red Hat.

O EXT3 possui uma vantagem significativa sobre todos os outros sistemas atuais, que é a sua total compatibilidade com o sistema de arquivos EXT2. O EXT3 é praticamente um EXT2 acrescido das propriedades de "journal". Conseqüentemente, pode empregar todas as aplicações existentes desenvolvidas para manipular o sistema de arquivos EXT2, bem como permitir uma migração para EXT3 sem grande esforço.

O EXT2 tem sido o sistema de arquivos mais popular para o GNU/Linux até o momento. Essa ampla base de usuários faz parecer que o EXT2 é o sistema de arquivos padrão do GNU/Linux. Tal afirmação não é de todo correta, já que o GNU/Linux reconhece os sistemas de arquivos através de uma funcionalidade incorporada ao kernel denominada VFS (Virtual File System). Não existe realmente um sistema de arquivos considerado padrão e sim o mais adotado pelos usuários.

Deste modo, o GNU/Linux pode reconhecer mais de vinte sistemas de arquivos em diferentes níveis de funcionalidade. Entre eles estão alguns que são proprietários e outros que são populares em diversas plataformas. Parte dessas características ainda é experimenta,l não estando totalmente funcionais. O padrão EXT3 pode ser assim compreendido, conforme NEMETH et al (2004):

Os dados do arquivo são armazenados em unidades chamadas 'blocos'. Estes blocos podem ser numerados seqüencialmente. Um arquivo também tem um inode. Como os blocos, os inodes são numerados seqüencialmente, embora tenham uma seqüência diferente. Uma entrada de diretório consiste do nome do arquivo e um número de inode. O inode também armazena o local dos blocos de dados, como se segue e conforme Figura 1:

• Os números dos blocos dos primeiros 12 blocos de dados estão armazenados diretamente no inode. Estes às vezes são chamados de blocos diretos.
• O inode contém o número do bloco de um bloco indireto. Um bloco indireto contém os números de blocos de 256 blocos de dados adicionais.
• O inode contém o número do bloco de um bloco duplamente indireto. Um bloco duplamente indireto contém os números de blocos de 256 blocos indiretos adicionais.
• O inode contém o número do bloco de um bloco três vezes indireto. Um bloco três vezes indireto contém os números de blocos de 256 blocos duplamente indiretos adicionais.

Fonte da Figura 1: Disponível em:
http://home.fhtwberlin.de/~s0503881/ext2_whatis.html.

"Um sistema de arquivos do tipo EXT3 consiste de cinco componentes estruturais:

• Células de armazenamento inode;
• Superblocos distribuídos;
• Mapa de blocos no sistema de arquivos;
• Resumo de emprego de blocos;
• Conjunto de blocos de dados.

Cada partição de sistema de arquivos é dividida em grupos de blocos. Estruturas como tabelas de inode são alocadas entre os grupos de blocos para que os blocos que são acessados juntos possam ser armazenados próximos uns dos outros no disco. Esse agrupamento aumenta a velocidade de acesso ao arquivo e reduz o tempo de procura por blocos do mesmo arquivo. Inodes são entradas de tabelas de comprimento fixo, cada uma das quais armazenam informações sobre um arquivo existente no sistema de arquivos." (NEMETH, et al, 2004, p. 106).

Os inodes são criados no momento da formatação lógica do dispositivo. Desta forma é possível redimensionar o número de inodes de acordo com a capacidade do dispositivo e o tipo e tamanho de arquivos que serão nele armazenados. Isso evita a falta de inodes que poderia provocar uma parada de sistema. Para determinar o tamanho do inode no momento da formatação é usado o comando mke2fs com opção -i bytes-por-inodes.

Observe que este ajuste é feito na criação da partição, não sendo possível redimensionar o número de inodes após a formatação inicial. A forma de disponibilizar inodes em um dispositivo é removendo arquivos que ocupam muitas entradas nas tabelas de blocos ou movendo-os para outros dispositivos.

Um superbloco é um registro que descreve as características do sistema de arquivos conforme Figura 2. Ele contém informações sobre:

• Comprimento de um bloco de disco;
• Tamanho e localização das tabelas de inodes;
• Mapa de blocos de disco e informações sobre utilização;
• Tamanho dos grupos de blocos;
• e outros parâmetros importantes para o sistema de arquivos.

Várias cópias do superbloco são gravadas em áreas diferentes do disco, (no início de cada grupo de bloco) prevenindo desse modo perdas de informações essenciais para o sistema de arquivos.

Fonte: Internet em:
http://home.fhtw-berlin.de/~s0503881/ext2_whatis.html

O GNU/Linux mantém para cada sistema de arquivos montado uma cópia do superbloco em memória RAM. A chamada de sistema "sync" despeja os dados sobre os superblocos que estão armazenados em memória cache para seus locais em disco, sincronizando as informações sobre o sistema de arquivos. Essa sincronização torna o sistema de arquivos consistente em um tempo extremamente pequeno. Esse salvamento ou sincronização ocorre em intervalos constantes de trinta segundos para sistemas EXT2 e a cada 5 segundos para EXT3, reduzindo, ainda mais, as falhas em servidores com intensas atividades de gravação de arquivos.

São descarregados tanto inodes modificados quanto blocos de dados armazenados em cache. O comando "update" executado no boot aciona o daemon bdflush, que executa uma sincronização nesse intervalo de tempo.

Um mapa de blocos do disco é uma tabela de blocos livres que o disco contém. No momento da gravação de arquivos novos esse mapa é verificado de modo que uma disposição eficiente seja utilizada. Os resumos de empregos de blocos registram informações básicas sobre os blocos que já se encontram em uso. (NEMETH, et al, 2004, p. 106).

Até esse ponto os sistemas EXT3 e EXT2 são totalmente iguais.

Essa estrutura que se utiliza de dados e metadados é bastante eficiente em termos de velocidade de tempo de acesso e permite armazenar um grande número de arquivos em tamanhos diversos. Contudo, o problema nessa abordagem é a baixa tolerância às falhas apresentada pelo EXT2.

Na ocorrência de falta de energia elétrica, por exemplo, podem surgir inconsistências entre os dados e os metadados. Nesse caso, uma região do disco poderia estar ocupada com dados sem que os metadados relacionados estivessem devidamente registrados apontando esse fato. Deste modo, uma perda de dados irá ocorrer no sistema de arquivos com a sobreposição dos dados por outros.

No caso de falhas ou interrupções bruscas do sistema elétrico, por exemplo, um utilitário chamado fsck (filesystem consistency check) é utilizado para restaurar a consistência do sistema de arquivos. Esse utilitário é confiável e apresenta um trabalho de recuperação bastante eficiente na verificação de erros e da consistência do sistema.

Os danos mais comuns averiguados pelo fsck em sua verificação são:

• Inodes não referenciados;
• Contagem de links exagerada;
• Blocos de dados não utilizados e não registrados nos mapas de blocos;
• Blocos de dados listados como livres e que são usados num arquivo;
• Informações de resumo incompletas no superbloco.

Esses cinco problemas são corrigidos de maneira segura e automática. O utilitário também é capaz de analisar erros e solicitar a intervenção do operador como nos casos de:

• Blocos reivindicados por mais de um arquivo;
• Blocos reivindicados fora do intervalo do sistema de arquivos;
• Contagem de links muito pequenos;
• Blocos não contabilizados;
• Diretórios que se referem aos inodes não alocados;
• Variados erros de formato. (NEMETH, et al ,2004, p. 109 e 110).

Corrigir um sistema de arquivos manualmente é uma tarefa complexa que exige do administrador conhecimentos sobre a estrutura e o funcionamento interno do sistema de arquivos. Alterações introduzidas nessa tentativa de recuperação que sejam indevidas podem danificar permanentemente o acesso aos dados.

Caso fsck localize um arquivo cujo diretório "pai" não pode ser encontrado, esse arquivo será salvo no diretório lost+found no nível mais alto do sistema de arquivos. Uma vez que os nomes dos arquivos são registrados somente em seus diretórios "pais", não é possível referenciar-se a esses arquivos por seus nomes. Os arquivos salvos nessa pasta terão como nomes seus números de inode.

A introdução do "journal" em sistemas EXT3 modifica essa abordagem de recuperação de sistemas de arquivos e reduz o tempo de parada do sistema para valores muito baixos, introduzindo uma confiabilidade muito superior ao servidor. Na instalação do sistema de arquivos, uma área é reservada para a alocação do "journal" ou "log".

Segundo NEMETH, et al (2004), as operações efetuadas nos arquivos são registradas nessa área de log do mesmo modo que o controle de transações em bancos de dados. As operações são primeiramente gravadas no journal. Quando a atualização do registro de ações (log) é completada, um registro de complemento (commit record) é gravado sinalizando o final da entrada. Então, as mudanças são efetivamente gravadas em disco no sistema de arquivos normal.

Uma falha nesse ponto permite, através da consulta ao journal, a reconstrução das operações ainda não concluídas e a rápida recuperação do sistema. Após a gravação em disco no sistema de arquivos, um marcador confirma a operação e descarta o log, já que a operação foi corretamente confirmada.

O EXT3 passou a ser suportado pelo kernel do Linux a partir da versão 2.4. Conseqüentemente, todas as distribuições Linux lançadas com esse kernel ou superior têm suporte padrão para EXT3.

De acordo com INFOWESTER (2004), no EXT3, o código de Journaling usa uma camada chamada "Journaling Block Device" (módulo JBD). A JBD foi criada com o propósito de implantar o suporte ao Journal em qualquer tipo de dispositivo com base em blocos de dados. Por exemplo, o código EXT3 informa e "pede autorização" à JBD para efetuar as mudanças antes de modificar/adicionar qualquer dado no disco. Sendo assim, é o JBD que verdadeiramente "gerencia" o Journal. Portanto, ele é uma dependência de módulo para o correto funcionamento do EXT3 juntamente com o módulo mbcache, que introduz uma camada cache para os metablocos melhorando o desempenho do sistema.

O JBD funciona como uma entidade independente permitindo que não só o EXT3 a use, mas, também, outros sistemas de arquivos. A JBD utiliza um método diferente de outros Journalings para recuperação de informações. Ao invés de armazenar as informações em bytes que depois devem ser gravados, a JBD grava os próprios blocos modificados do sistema de arquivos. Assim, o EXT3 também armazena "réplicas" completas dos blocos modificados em memória para rastrear as operações que ficaram pendentes. A desvantagem desta forma de trabalho é que o Journal acaba sendo maior.

No entanto, o EXT3 não precisa lidar com a complexidade dos Journalings que trabalham gravando bytes. Ele suporta três diferentes modos de trabalho do Journaling, de acordo com NEMETH, et al (2004) e INFOWESTER (2004):

• Journaling (Registro de ações): grava todas as mudanças em sistema de arquivos e usa um arquivo de registros de ações maior. Isso pode retardar a recuperação durante a reinicialização. É o mais lento dos três modos, sendo o que possui maior capacidade de evitar perdas de dados. Uma forma de aperfeiçoar a velocidade dessa opção é gravar os registros em bancos de dados externos.
• Ordered (Ordenado): grava somente mudanças em arquivos metadados (arquivos que possuem informações sobre outros arquivos), mas registra as atualizações no arquivo de dados antes de fazer as mudanças associadas ao sistema de arquivos. Este Journaling é o padrão nos sistemas de arquivos EXT3 sendo a melhor opção para a maioria dos sistemas.
• Writeback: também só grava mudanças para o sistema de arquivo em metadados, mas utiliza o processo de escrita do sistema de arquivos em uso para gravação. É o mais rápido Journaling EXT3, porém é o menos confiável e mais suscetível à corrupção de arquivos após uma queda do sistema. Esse modo é equivalente à instalação de um sistema com EXT2 nativo.

O modo Ordered é o padrão no EXT3, mas é possível especificar qual o modo que se deseja usar através da modificação no arquivo /etc/fstab do parâmetro data="mode", onde "mode" pode ser igual a ordered, writeback ou journal. Por exemplo, uma entrada no /etc/fstab, usando o modo journal como padrão:

Devido à compatibilidade entre o sistema EXT2 e seu sucessor EXT3, é possível realizar uma migração apenas incluindo a área destinada ao registro das ações. O utilitário que faz essa configuração é o tune2fs com opção -j.

Por mais que seja segura a migração, é imprescindível efetuar cópia de segurança antes do procedimento e garantir que nenhum usuário obtenha acesso ao sistema nesse momento para evitar perdas dos dados. Por exemplo, para migrar uma partição EXT2 em /dev/hda3 para EXT3 usa-se:

# tune2fs -j /dev/hda3

Após a conclusão do comando é necessário alterar o tipo de partição no /etc/fstab para que esta seja corretamente montada. É possível montar uma partição EXT3 como EXT2, porém, isso não é recomendável, pois pode causar danos inesperados aos dados.