Ext

O Ext (extended file system) foi o primeiro sistema de arquivos criado especificamente para o Linux. Ele foi desenvolvido por Rémy Card para substituir o sistema de arquivos do MINIX (Minix FS), que havia sido inicialmente utilizado por Linus Torvalds para o recém-criado Linux. A versão do sistema de arquivos do Minix adaptada por Torvalds possuía limitações importantes. O Ext foi criado para resolver essas limitações e incluído no Linux 0.96c (julho de 1992). Seu desenvolvimento foi facilitado pela implantação do VFS (virtual file system), inicialmente escrito por Chris Provenzano e posteriormente reescrito por Linus Torvalds. O VFS foi incorporado ao Linux 0.96a (maio de 1992).

A partir de 1993 o Ext passou a sofrer a concorrência do Xia FS e do Ext2. Ambos apareceram no Linux 0.99.7 (Janeiro de 03). O Ext foi utilizado até a versão 2.0 do Linux, tendo desaparecido a partir da versão 2.2.0 (de janeiro de 1999).

O Ext ainda era limitado em comparação com o Xiafs e o Ext2. Além dos tamanhos máximos (para volumes, arquivos e nomes), o Ext (assim como o Minix FS) usava apenas um rótulo de tempo, enquanto o Xia FS e o Ext2 passaram a registrar os tempos de acesso (atime), alteração de metadados (ctime) e modificação dos dados (mtime) do arquivo. Esses rótulos também são conhecidos por MAC times.

Comparativo de algumas características de sistemas de arquivos Linux:

Ext2

O Ext2 (Second Extended file system) é um sistema de arquivos para dispositivos de blocos (disco rígido, disquete, pen drive). Foi desenvolvido para o Linux por Rémy Card para substituir o Ext (Extended file system), que também havia sido criado por Rémy Card.

Esta seção é baseada no texto de Card, Ts'o e Tweedie [1994].

Linus Torvalds adaptou o sistema de arquivos do MINIX, de Andrew Tanenbaum, para o Linux. Entretanto, aquele sistema tinha várias limitações, como o tamanho do volume suportado (máximo de 64 MiB) e nome de arquivos (até 14 caracteres).

Após a inclusão do VFS (Virtual Filesystem) no núcleo inicialmente escrito por Chris Provenzano, depois reescrito por Torvalds, Rémy Card criou o Ext em 1992, que foi incluído no Linux 0.96c. Esse sistema de arquivos estendeu o limite do volume para 2 GiB e o tamanho do nome de arquivo para 255 caracteres.

O Ext ainda tinha alguns problemas, como a falta de suporte a modificação em nós-i e no tempo de modificação do arquivo. E com o uso, o sistema ficava fragmentado e lento. No início de 1993 foram disponibilizados 2 novos sistemas: o XiaFS, de Frank Xia, também baseado no Minix; e o Ext2, que tornou-se o sistema de arquivos padrão para instalações Linux.

Ext2 foi projetado e implementado para corrigir as deficiências do Ext e prover um sistema que respeitasse a semântica UNIX. A influência do UNIX pode ser vista, por exemplo, na utilização de grupos de blocos, que são análogos aos grupos de cilindros utilizados pelo FFS [CARD, TS'O & TWEEDIE, 1994]. A versão original do FFS originou o que é hoje conhecido como UFS1 (Unix File System 1)

O bloco, que consiste num conjunto de setores (cada setor tem 512 bytes), é a menor unidade de alocação para o Ext2. O tamanho pode ser de 1024, 2048 ou 4096 bytes e é definido na formatação.

O tamanho máximo de um volume Ext2 é de 8 TiB [MINGMING CAO et al, 2005]. Embora o superbloco (v. abaixo) contenha um campo de 32 bits que determina o número de blocos (s_blocks_count), o que permitiria armazenar até 16 TiB, o tamanho é limitado pelo número de grupos de bloco, que é de 65 536 (determinado pelo campo s_block_group_nr), pois o campo ocupa dois bytes (16 bits). Assim, caso o volume seja formatado usando blocos de 4 KiB, cada grupo de blocos tem até 32 768 blocos; com 65 536 blocos obtém-se o limite indicado (4 KiB * 32 768 * 65 536 = 8 589 934 592 KiB = 8 TiB).

As subseções a seguir descrevem, resumidamente, as estruturas do Ext2 (superbloco, nó-i, grupos de blocos, mapas de bits de blocos e de nós-i e tabelas de nós-i), que são mostradas com mais profundidade e detalhamento por Carrier [2005, pp. 449–460], Bovet & Cesati [2005, pp. 741–746] e, principalmente, no código fonte do Linux, neste texto foi usado como referência a versão 2.6.28.8 (de março de 2009) 

                               Ext3

O EXT3 é atualmente o sistema de arquivos mais utilizado no mundo Linux. Usado por padrão pela grande maioria das distribuições. O EXT2 trouxe suporte a partições de até 32 TB, manteve o suporte a nomes de arquivos com até 255 caracteres, além de diversos outros recursos.

O maior problema do EXT2 é que ele não inclui nenhum sistema de tolerância a falhas. Sempre que o sistema é desligado incorretamente, é necessário utilizar o fsck, um utilitário similar ao scandisk do Windows, que verifica todos os blocos do sistema de arquivos, procurando por inconsistências entre as estruturas e descrições e os dados efetivamente armazenados.

O teste do fsck demora bastante (bem mais que o scandisk) e o tempo cresce proporcionalmente de acordo com o tamanho da partição. Em um HD atual, o teste pode, literalmente, demorar horas.

Este problema foi corrigido com o EXT3, que foi introduzido em 1999. A principal característica do EXT3 é o uso do recurso de journaling, onde o sistema de arquivos mantém um journal (diário) das alterações realizadas, um recurso similar ao LFS usado no NTFS.

Este "diário" armazena uma lista das alterações realizadas, permitindo que o sistema de arquivos seja reparado de forma muito rápida após o desligamento incorreto. O fsck continua sendo usado, mas agora ele joga de acordo com as novas regras, realizando o teste longo apenas quando realmente necessário.

O EXT3 possui três modos de operação:

No modo ordered (o default), o journal é atualizado no final de cada operação. Isto faz com que exista uma pequena perda de desempenho, já que a cabeça de leitura do HD precisa realizar duas operações de gravação, uma no arquivo que foi alterada e outra no journal (que também é um arquivo, embora especialmente formatado) ao invés de apenas uma.

No modo writeback o journal armazena apenas informações referentes à estrutura do sistema de arquivos (metadata) e não em relação aos arquivos propriamente ditos, e é gravado de forma mais ocasional, aproveitando os momentos de inatividade. Este modo é o mais rápido, mas em compensação oferece uma segurança muito menor contra perda e corrompimento de arquivos causados pelos desligamentos incorretos.

Finalmente, temos o modo journal, que é o mais seguro, porém mais lento. Nele, o journal armazena não apenas informações sobre as alterações, mas também uma cópia de segurança de todos os arquivos modificados, que ainda não foram gravados no disco. A cada alteração, o sistema grava uma cópia do arquivo (no journal), atualiza as informações referentes à estrutura do sistema de arquivos, grava o arquivo e atualiza novamente o journal, marcando a operação como concluída. Como disse, isso garante uma segurança muito grande contra perda de dados, mas em compensação reduz o desempenho drasticamente. Justamente por causa disso, este é o modo menos usado.

Para usar o modo writeback ou o modo journal, você deve adicionar a opção "data=writeback", ou "data=journal" nas opções referentes à partição, dentro do arquivo "/etc/fstab".

Desta forma, ao invés de usar "/dev/hda5 /mnt/hda5 ext3 defaults 0 2", por exemplo, você usaria "/dev/hda5 /mnt/hda5 ext3 data=writeback 0 2"

O EXT3 (assim como o EXT2) utiliza endereços de 32 bits e blocos (análogos aos clusters usados no sistema FAT) de até 8 KB. Tanto o tamanho máximo da partição, quanto o tamanho máximo dos arquivos são determinados pelo tamanho dos blocos, que pode ser escolhido durante a formatação:

Tamanho dos blocos Tamanho máximo da partição Tamanho máximo dos arquivos

1 KB 2 TB 16 GB

2 KB 8 TB 256 GB

4 KB 16 TB 2 TB                 

8 KB 32 TB 2 TB

                                Ext 4

O ext4 é a evolução do conhecido ext3, hoje o file-system padrão do GNU/Linux. O Linux oferece suporte a uma infinidade de file-systens e em uma instalação normal do sistema, os file-systens mais famosos são o reiserfs e o ext3. Ambos tem suas qualidades e deficiências que fazem com que um seja superior ao outro em alguns aspectos e vice-versa; situação que divide a opinião de muitos usuários. Na prática, podemos resumir (muuuito resumidamente), que o reiserfs tem mais eficiência com arquivos de tamanho grande enquanto que o ext3 é mais rápido que o reiserfs na manipulação de arquivos pequenos. Tanto o reiserfs quanto o ext3 contam com o Journaling, um setor do file-system onde é feita a reportagem (journaling) de todas as ações feitas no hd antes de se escrever diretamente no file-system. Assim, em casos de sinistros, como um desligamento inadequado ou uma queda de energia, basta que o filesystem consulte a seção de journaling e restaure tudo o que foi perdido sem a necessidade de uma checagem completa. Nesse aspecto, ext3 e reiserfs se comportam de formas diferentes. Enquanto o reiserfs privilegia a restauração imediata, o ext3 se preocupa em restaurar tudo na íntegra, o que resulta em consulta e restauração mais lenta, porém mais exata. O problema é que por ser mais lento, pode ocorrer um novo desligamento inadequado no momento exato em que o journaling está sendo atualizado :-(.

Atualmente ambos os file-systens estão em fase de evolução, mas o reiserfs vem encontrando vários problemas, principalmente de ordem administrativa, como a prisão de Hans Reiser, seu desenvolvedor, enquanto que o ext3 evolui a passos largos para o ext4. No atual momento em que este artigo é escrito, o ext4 já é totalmente suportado pelas novas versões do kernel e já é possível usá-lo em nossos computadores e em servidores para testes.

As novidades do novo ext4:

Com o passar dos tempos, muitos eventos forçaram a equipe de desenvolvimento do extfs (o nome da familia de file-system, compostas pelo ext2, ext3 e o futuro ext4) a desenvolver essa nova versão, até por que, o ext4 está mais para uma atualização do ext3 (em outros lugares, chamam isso de Service Pack :-P ) do que para uma versão nova. Isso por que nesse período de tempo, os desenvolvedores do extfs inflaram o ext3 com uma série de recursos complexos que, apesar de úteis, geraram alguns problemas como:

 

·         Alguns recursos novos encontraram problemas de incompatibilidade;

·         O código ficou altamente complexo e dificílimo para se manter;

·         As mudanças que deveriam causar alta disponibilidade estavam o tornando indisponível.

Por esses motivos, os desenvolvedores decidiram fazer um fork (nome dado a um programa que surge a partir do código do outro, com algumas modificações) do ext3, implementando novos recursos e que foi batizado de ext4.

O ext4 já era suportado desde a versão 2.6.19 do Kernel, porém, como ele vinha marcado como alpha, a maioria dos administradores não davam muita bola para ele. Esse quadro mudou a partir da versão 2.6.24.4 do kernel, que passou a dar suporte integral ao ext4 e todos os novos recursos, agora plenamente suportados. Dentre alguns desses recursos, podemos citar:

File system Gigante: O ext3 conseguia fazer uma partição de, no máximo, 32 TB (terabytes) e manipular arquivos de até 2 TB de tamanho. Isso é o que diz a teoria (e a documentação) por que na prática, esses números variam muito de acordo com a configuração do sistema e da arquitetura usada, a média seria algo como 2 TB para um file-system e 16GB para um arquivo.

O ext4, no entanto, tem uma margem real bem maior que essa: 1024 PB (petabytes) ou 1EB (exabyte) para partições e 16TB por arquivo. Isso ainda não é importante para servidores simples ou desktops, mas com certeza vai se tornar útil para servidores grandes, configurados em Raid e de alta disponibilidade.

Melhorias na pré-alocação: As vezes, um programa vai usar um espaço do hd mas não na hora, então ele reserva o espaço que vai usar, fazendo uma pré-alocação, ou seja, ele guarda aquele espaço pra ele e ninguém mais pode usar, como se fosse uma reserva. Para essa ação, a maioria dos file-systens enchem de zeros os Inodes que eles vão reservar. Quando essa ação é executada milhares de vezes, como em um banco de dados, esse tempo de escritas de zeros geram um delay de tempo desnecessário. O ext4 vai permitir pré-alocação de arquivos sem fazer isso, o que vai garantir uma melhoria na performance, principalmente nas rotinas de bancos de dados e em ferramentas multimidia.

Tempo de alocação extendido: O ext4 vai conseguir manter a alocação do espaço em disco até o último momento, o que pode trazer mais performance.

Maior números de subdiretórios: O ext3 colocava um limite de subdiretórios por pastas de 32000 pastas, se você achava isso um incômodo, boas notícias: não haverá limites para o ext4.

Checksum para o Journaling: Lembra-se daquele probleminha do journaling no ext3 que eu havia comentado no início desse artigo? Então.. resolvido. Haverá checagem no Journaling, garantindo uma restauração mais rápida e a prova de falhas.

Desfragmentação On-Line: Sim.. parece mentira mas o ext3 deixava os arquivos com um pouquinho, mas bem pouquinho de fragmentação. Agora não deixa mais. O ext4 vai desfragmentando enquanto os arquivos vão sendo alocados.

Undelete: Undelete é uma ferramenta disponível no ext4 que impede que um arquivo seja apagado. Isso pode ser muito útil para arquivos e pastas que não podem ser apagados e, por estarem direto no file-system, encontram-se acima do bem e do mal, até mesmo sobre a autoridade do root, anulando em definitivo a possibilidade de um apagamento acidental do arquivo.

Checagem rápida do file-system: O fsck está mais rápido por que a nova estrutura de organização de blocos permite que partes não usadas do hd sejam puladas, o que economiza tempo numa eventual checagem.

Como o ext4 ainda está em fase de desenvolvimento, alguns recursos listados podem não trabalhar como se espera ou podem não estar totalmente implementados e o uso de outros pode causar incompatibilidades com o ext3 (Um file sistem ext3 pode ser montado como ext4, mas o inverso ainda não é possível).