1. Sistema de arquivos Ext
Gustavo Henrique Gomes 1
, Jo˜ao Batista P. Matos Jr.1
,
Pedro Antˆonio Braganick Costa1
, Vin´ıcius de Sousa Coelho1
1
Instituto de Inform´atica – Universidade Federal de Goi´as (UFG)
Goiˆania – GO – Brasil
{joaobatistamatos, pedrobraganick, viniciuscoelho}@inf.ufg.br
{gustavogomes582}@gmail.com
Abstract. This article was developed and presented as seminary in Operational
Systems II class, for the course of Computer Science. The theme is related to
ExtFS, a file system developed essentially for Linux.
Resumo. Este artigo foi desenvolvido e apresentado como semin´ario na dis-
ciplina de Sistemas Operacionais II, referente ao curso de Ciˆencias da
Computac¸˜ao. O tema abordado ´e relacionado ao ExtFS, um sistema de arquivos
desenvolvido especificamente para Linux.
1. Introduc¸˜ao
Historicamente, o Extfs foi desenvolvido em 1992 por R´emy Card. Foi o primeiro sis-
tema de arquivos desenvolvido especificamente para Linux, substituindo as limitac¸˜oes do
sistema de arquivo Minix, conhecido como MinixFS. Entre elas podemos citar:
• O tamanho das partic¸˜oes era limitado para 64MB;
• Os nomes de arquivos n˜ao podiam ultrapassar os 14 bytes.
O MinixFS foi desenvolvido para uso no Minix, um sistema operacional criado
por Andrew Tanenbaum em meados de 1980, como um sistema operacional Unix-like
(que tem comportamento semelhante ao Unix), cujo c´odigo fonte era livre. O MinixFS
copiava a estrutura b´asica do UFS (Sistema de Arquivos do Unix, em portuguˆes), mas
sem muitos m´etodos complexos, deixando o c´odigo enxuto. O formato ainda ´e utilizado
em algumas distribuic¸˜oes Linux para discos boot´aveis e outras situac¸˜oes onde um sistema
de arquivos simples e compacto ´e necess´ario.[MinixFS at Wikipedia ] O Extfs encontrou
sua inspirac¸˜ao no tradicional UFS e consequentemente usa o mesmo tipo de metadados,
chamados i-nodes, que podem ser considerados a base do sistema de arquivos. Ele foi
simplificado, embora todas estruturas obsoletas do UFS mantidas para compatibilidade
foram removidas. Os tamanho limite de 64MB para as partic¸˜oes do MinixFS n˜ao existia
mais, passando a ter limite de at´e 2GB e o nome dos arquivos poderiam ent˜ao conter at´e
255 caracteres. R´emy Card, n˜ao satisfeito com o ext, substituiu-o em 1993 pelo sistema
de arquivo ext2, cujo objetivo era prover um sistema de arquivos poderoso, que imple-
mentasse semˆanticas de arquivos Unix e oferecer caracter´ısticas avanc¸adas. J´a em 2001,
foi lanc¸ado o ext3, que ´e um ext2 com journal e outras caracter´ısticas, como por exemplo,
suporte a arquivos grandes. Em 2006, em fase experimental, foi lanc¸ado o ext4 usando
o extents, grac¸as as melhorias de velocidade nos dispositivos de I/O, al´em de suportar
arquivos individuais na casa de TB. Em 2008 saiu a primeira vers˜ao est´avel do ext4, mas,
ainda hoje, muitos usu´arios ainda utilizam o ext3. Maiores detalhes ser˜ao discutidos pos-
teriormente. [Framework ]
2. 2. Limite de arquivos
2.1. Ext
O Ext limita o tamanho dos nomes em apenas 255 caracteres, para tamanho de arquivo o
limite m´aximo ´e de 2GB, o mesmo para partic¸˜ao de sistema.
2.2. Ext2
Second Extended File System ou Ext2, foi criado para corrigir deficiˆencias encontradas
no seu antecessor, que era apenas uma adaptac¸˜ao de outro sistema de arquivos. O ext2
procurou seguir a mesma semˆantica do UNIX. Houve melhorias consider´aveis no Ext2:
• N˜ao h´a limites para o tamanho de extens˜oes de arquivos;
• Um arquivo pode ter v´arias extens˜oes ao mesmo tempo;
• O tamanho m´aximo de arquivos passou de 2GB para 16GB a 2TB, dependendo
do tamanho dos blocos que ´e vari´avel sendo 1KB, 2KB, 4KB ou 8KB.
O volume m´aximo do Ext2 ´e de 32TB. No Linux esse tamanho ´e limitado pelo
tamanho do superbloco que ´e 32 bits, fazendo teoricamente o Ext2 poder armazenar at´e
16TB com 32 bits, mas ´e limitado pelo n´umero de grupo de blocos (65.536), que ocupa 16
bits. Fazendo uma conta simples para blocos de 4KB com cada grupo de blocos contendo
no m´aximo 32.768 blocos e o limite de grupo sendo 65 536, temos 4 ∗ 32.768 ∗ 65.536 =
8TB. O n´umero m´aximo de sub-n´ıveis de diret´orio ´e de 31.998, n˜ao existindo indexac¸˜ao
de arquivo no Ext2. Sendo assim, existe perca de desempenho em diret´orios com mais de
10.000 arquivos.
2.3. Ext3
Third Extended File System ou Ext3 ´e o sucessor do Ext2. Sua mudanc¸a mais relevante
´e a introduc¸˜ao do journaling, que ´e usado pelo kernel linux. Isso torna o Ext3 muito mais
confi´avel e elimina a necessidade de checar o sistema de arquivos ap´os um desligamento
inesperado do sistema. H´a uma queda na performance em comparac¸˜ao com o Ext2, mas
possui vantagens em confiabilidade, crescimento do sistema de arquivo de forma online
e indexac¸˜ao por H-Tree (vers˜ao especial de B-Tree) para diret´orios com muitos arquivos.
Existem 3 tipos de journaling:
• Menor risco, que grava tudo em um journal antes de passar para o sistema de
arquivos. Isso geralmente causa perca de performance, pois os dados acabam
sendo escritos duas vezes: uma para o journal e outra para o sistema de arquivos.
• Risco m´edio, onde apenas os metadados s˜ao escritos no journal e o conte´udo dos
arquivos n˜ao, mas ´e garantido que este conte´udo seja escrito no disco antes que os
metadados correspondentes sejam marcados como submetidos no journal. Caso
haja erro no sistema, o arquivo ser´a limpado pelo processo de cleanup; no caso
de arquivos sendo sobrescritos, podem ser corrompidos porque a vers˜ao original
do arquivo n˜ao for guardada, o que acaba colocando o arquivo em um estado
inconsistente e sem informac¸˜ao suficiente para restaurar completamente nenhum
dos dois estados. Sendo assim, pode haver mistura de dados novos e antigos, pois
a ordem escrita ´e controlada pelo pr´opio hardware do disco.
3. • Risco mais alto, somente os metadados s˜ao escritos no journal, o conte´udo dos
arquivos n˜ao. Assim o conte´udo pode ser escrito antes ou depois que o journal ´e
atualizado, tendo como consequˆencia arquivos corrompidos em caso de erro. Um
arquivo pode ser marcado no journal como sendo maior do que ele realmente ´e,
causando inconsistˆencias. Vers˜oes antigas podem sobrescrever novas pois pode
haver falta de sincronizac¸˜ao entre dados e journal.
Ext3 possui blocos de at´e 8KB, cujo n´umero m´aximo de blocos ´e de 232
. No ext2,
para cada tamanho de bloco existe um tamanho de arquivo e sistema m´aximo, sendo que o
tamanho ´e de 16GB a 2TB e de 2TB a 32TB respectivamente. O tamanho dos superblocos
ainda permanece 32 bits.
2.4. Ext4
Ext4 ´e sucessor do Ext3 criado para remover alguns limites do armazenamento em 64 bits.
Usa blocos de 4KB, o tamanho de arquivos pode ser de at´e 16TB e de partic¸˜ao de sistema
at´e 1EB. ´E introduzido extends para substituir o tradicional esquema de mapeamento de
blocos usado pelo Ext2 e Ext3. Um extends ´e uma s´erie de blocos f´ısicos que melhora
a performance de arquivos grandes, reduzindo fragmentac¸˜ao. Uma ´unica extens˜ao pode
mapear at´e 128MB de espac¸o com um tamanho de bloco de 4KB, podendo haver at´e
4 extens˜oes armazenados em um ´unico i-node. Quando h´a mais que 4 extens˜oes para
um arquivo, elas s˜ao indexados em uma H-Tree. N˜ao h´a mais limite de 32.000 sub-
diret´orios; no Ext4 ´e aumentado para 64.000, sendo poss´ıvel ir al´em com a funcionalidade
”dir nlink”. No Ext4, um grupo de blocos n˜ao alocados e sec¸˜oes da tabela de i-node s˜ao
marcados como tal. Com isso, o e2fsck pode pular inteiramente em uma checagem os
blocos, o que reduz muito o tempo para uma partic¸˜ao do tamanho que existe no Ext4. H´a
tamb´em o acr´escimo de 2 bits no campo do timestamp, em virtude de adiar o problema
do ano 2038 por mais 204 anos.
3. Entradas e Performance
Algumas comparac¸˜oes entre as variac¸˜oes do ext [fsck time vs. inode count ], [Dell ]:
Figure 1. Gr´afico de uma checagem de arquivos para Ext2, Ext3 e Ext4
4. Figure 2. Gr´afico de desempenho em escrita em Raid feito IOZone
Figure 3. Gr´afico de desempenho em leitura em Raid feito IOZone
4. Gerenciamento de Blocos
De modo geral no sistema de arquivos Ext2, arquivos s˜ao guardados (armazenados) em
blocos, estes por sua vez s˜ao agrupados em grupos de blocos. E todas as informac¸˜oes
sobre a configurac¸˜ao do sistema de arquivos est´a presente no superbloco e i-nodes. O
bloco ´e a menor unidade de alocac¸˜ao e possuem tamanhos fixos que podem ser de 1024,
2048 ou 4096 bytes. Esses tamanhos s˜ao definidos no momento da criac¸˜ao do sistema
de arquivo, e impactam diretamente na organizac¸˜ao, controle e ocupac¸˜ao do disco. O
tamanho do bloco ´e proporcional ao desperd´ıcio de espac¸o por arquivo, contudo ´e inver-
samente proporcional a sobregaca de contagem e ao n´umero de blocos para gerenciar.
Os grupos de blocos s˜ao implementados (de uma forma organizacional) para minimizar
a fragmentac¸˜ao, por consequˆencia isso tamb´em diminui o tempo de seek, uma vez que
se possibilita ler um volume muito maior de dados cont´ıuos, agilizando a leitura de um
arquivo, e/ou blocos. Cada grupo possui um bloco com uma c´opia do superbloco do sis-
tema de arquivos, n blocos para uma c´opia do descritor de grupos, um bloco para mapa de
bits dos bloco, outro bloco para o mapa de bits de i-nodes e mais n blocos para a tabela
de i-nodes.
O descritor de grupos mant´em as informac¸˜oes sobre todo o conte´udo de grupo
de blocos, [de grupos EXT2 ]. Os mapas de bits(bitmap) de blocos e mapas de bits de
i-nodes guardam a informac¸˜ao sobre quais blocos est˜ao em uso e quais i-nodes est˜ao em
uso, valor 0 indica bloco vazio e valor um bloco ocupado, bitmap de i-nodes funciona
de forma an´aloga. Tanto no mapa de bits de bloco quanto no de i-nodes, cada byte pode
referenciar oito blocos, ou seja um bit para cada bloco.
5. Figure 4. Representac¸ ˜ao de uma partic¸ ˜ao EXT2 e de um Grupo de blocos
Figure 5. Tabela com os campos de um descritor de grupos EXT2
Quanto ao superbloco [EXT2 ], diz-se que ´e uma estrutura essencial para a mon-
tagem do sistema de arquivos e ocupa um espac¸o de 1024 bytes do inicio do dispositivo.
Devido a sua importˆancia tem-se uma c´opia para cada grupo de blocos existente no sis-
tema de arquivos. As principais informac¸˜oes do superbloco s˜ao o n´umero total de blocos
e i-nodes no sistema de arquivos e quanto deles est˜ao livres, o n´umero de i-nodes e blocos
para cada grupo de blocos. Todos os campos do superbloco s˜ao preenchidos usando a
arquitetura little endian.
I-node (index node) ´e uma estrutura de dados de tamanho 128 fundamental ao sis-
tema de arquivos EXT2. Para qualquer objeto presente neste sistema de arquivos, haver´a
um i-node o representando. Cada i-node cont´em ponteiros que para os blocos onde est˜ao
as informac¸˜oes do objeto, como os dados nele armazenados e metadados tais como per-
miss˜oes, dono, tamanho, ´ultima modificac¸˜ao, numero de blocos, fragmentos, vers˜ao e etc;
as ´unicas informac¸˜oes que n˜ao s˜ao encontradas no i-node s˜ao o nome do objeto e o nome
do seu diret´orio pai. O i-node [I-node ] cont´em ainda ponteiros para blocos indiretos,
que por sua vez podem conter ponteiros para mais blocos indiretos, antes de terem pon-
teiros para dados necessariamente. Este apontamento indireto permitem arquivos muito
extensos.
No EXT2, os dados tendem a ser colocados no mesmo grupo de blocos, para tentar
diminuir o efeito da fragmentac¸˜ao, que ´e inevitavel. Nem sempre arquivos ter˜ao mesmo
tamanho dos blocos, ou n˜ao caberam todos exatamente em um grupo de blocos, o que
deixar´a certo desperd´ıcio em cada bloco e/ou grupo de blocos. A fragmentac¸˜ao se divide
em dois casos; interna e externa. Na fragmentac¸˜ao interna, um arquivo cabe dentro de um
grupo de blocos, mas n˜ao ´e capaz de ocupar todos os blocos do grupo deixando um espac¸o
livre que n˜ao poder´a ser ocupado por outro arquivo. Na externa, ocorre que o arquivo ´e
muito grande e tem-se a necessidade de divid´ı-los em mais de um grupo de blocos. As
soluc¸˜ao para fragmentac¸˜ao interna ´e diminuir o tamanho do blocos, contudo isso n˜ao ´e
interessante pois pode afetar a performance do sistema, pois como visto anteriormente
6. Figure 6. Tabela com os campos de um Superbloco EXT2
aumentaria o numero de blocos para gerenciar. Quanto a externa o Ext2 disponibiliza
at´e oito blocos, tentando disponibilizar todos em sequˆencia, para um arquivo aberto para
gravac¸˜ao. O sistema de arquivos Ext4, apresenta um mecanismo de alocac¸˜ao atrasada e
pr´e-alocac¸˜ao persistente de espac¸o em disco. Na pre-alocac¸˜ao persistente usa-se agora a
func¸˜ao fallocate() que alocar´a um espac¸o continuo no disco para a alocac¸˜ao, n˜ao necessi-
tando de gerar um arquivo vazio preenchido com zeros como era feito anteriormente. Na
alocac¸˜ao atrasada utiliza-se a t´ecnica allocate-on-flush, essa t´ecnica funciona atrasando a
alocac¸˜ao de blocos at´e que toda a informac¸˜ao esteja dispon´ıvel para gravar no disco.
5. Aspecto de seguranc¸a e Diret´orios
5.1. Evoluc¸˜ao em cada vers˜ao
Com relac¸˜ao a diret´orios o ext era extremamente limitado quando comparado `as demais
vers˜oes desse sistema, o ext2 passa a enxergar os diret´orios como um arquivo especial
que cont´em uma lista dos subdiret´orios e arquivos subordinados a ele, o ext2 tamb´em
conta com um m´aximo de 31.998 subdiret´orios, al´em disso no ext2 cada diret´orio tem
no m´aximo 32TB de tamanho. A vers˜ao ext3 n˜ao aumentou o tamanho do diret´orio e
t˜ao pouco o n´umero de subdiret´orios que continuaram na faixa de 32.000, ao inv´es disso
nessa vers˜ao os diret´orios passaram a ser representados por uma H-tree que consiste em
uma ´arvore especializada em dados utilizada para a indexac¸˜ao do diret´orio. O ext4 por sua
vez ampliou muito as limitac¸˜oes de seus antecessores com um limite m´aximo de tamanho
para os diret´orios de 1EB e cerca de 64.000 diret´orios de sub-n´ıvel e esse n´umero pode
ser ainda maior com a funcionalidade ”dir nlink” onde embora o n´umero de subdiret´orios
7. Figure 7. I-node EXT2
possa ser maior a contagem de diret´orios na pasta pai congele em 64.000. J´a com relac¸˜ao
`a seguranc¸a e confiabilidade a principal mudanc¸a ocorreu entre o ext2 e o ext3 com a
adic¸˜ao do journaling, uma ferramenta que funciona como um log de todas as atividades
ocorrentes no sistema de arquivos ou em alguns casos um log parcial das ocorrˆencias, o
que facilita na detecc¸˜ao e correc¸˜ao de erros, mas que por sua vez pode comprometer o
desempenho.
5.2. Journaling
Basicamente o journaling ´e um jornal, ou seja, um log dos eventos do sistema de arquivo,
atrav´es do armazenamento de dados sobre todas as operac¸˜oes feitas no sistema de arquivos
at´e que as mesmas sejam completamente realizadas esse m´etodo ´e capaz de detectar e
corrigir erros sem a necessidade de verificar todo o disco, precavendo o sistema de perca
mesmo que o sistema seja desligado incorretamente. A desvantagem desse m´etodo est´a
no desempenho das atividades, uma vez que cada atividade deve especificar no log oque
vai ocorrer e s´o depois a mesma ser´a realmente executada. Esse m´etodo foi inclu´ıdo no
ext3 e melhorado no ext4, e pode ser utilizado em trˆes variac¸˜oes:
• Journal: Nesse caso todas as atividades e modificac¸˜oes feitas no sistema de ar-
quivos s˜ao adicionadas ao log o que deixa o sistema mais seguro em relac¸˜ao as
outras duas variac¸˜oes mas que por sua vez com o menor desempenho.
• Write Back: Esse por sua vez gera uma confiabilidade mais baixa que os de-
mais uma vez que armazena no log somente mudanc¸as em arquivos que possuem
metadados, por´em isso faz com que o desempenho seja maior.
• Ordered: O meio termo entre as trˆes variac¸˜oes e a comumente usada no ext3,
nessa variac¸˜ao ´e armazenado no log somente modificac¸˜oes feitas em arquivos com
metadados, mas al´em disso guarda no arquivo de dados as atualizac¸˜oes antes de
fazer as mudanc¸as associadas ao sistema de arquivos.
O ext3 possui tamb´em uma camada chamada ”Journaling Block Device” (JDB),
essa camada funciona com o objetivo ´unico de facilitar o journaling no sistema de arquivos
8. de forma a tratar os dados a serem armazenados no log como blocos, fazendo com que
os dados guardados sejam r´eplicas perfeitas dos blocos que est˜ao sendo modificados, o
jdb ent˜ao gerencia o jornal mantendo a log (r´eplica dos blocos) na mem´oria at´e que a
operac¸˜ao seja confirmada. ´E importante ressaltar que o JDB n˜ao faz parte do sistema de
arquivos ele ´e uma ferramenta independente e pode inclusive ser usado por mais de um
sistema de arquivo.
5.3. H-Tree
At´e a vers˜ao ext2 os diret´orios armazenavam seus subdiret´orios e arquivos em uma lista
ligada, por´em a busca linear feita sobre essa lista comec¸ou a comprometer o desempenho
do sistema de arquivo, ent˜ao a partir do ext3 foi implementada a H-tree como estrutura
de dados para armazenamento dos subordinados de determinado diret´orio. A H-Tree ´e
basicamente uma ´arvore B, por´em possui 32 bits para hash dos elementos, onde cada
chave referencia um conjunto de entradas guardado em um n´o folha. Como na H-Tree
cada n´o interno tem 8 bytes sabemos que o espalhamento dos blocos ´e muito grande,
pode-se referenciar 500 blocos usando um bloco com 4K entradas, apenas dois n´ıveis da
´arvores s˜ao suficientes para armazenar 16 milh˜oes de nomes contendo 52 caracteres, por
esse motivo em geral as H-Trees tem no m´aximo dois n´ıveis. Como o espalhamento na
arvore h ´e muito grande e ao mesmo tempo o diret´orio possui um hash direcionado a ele
pelo nome n˜ao ´e necess´ario um balanceamento nessa ´arvore.
6. Conclus˜ao
O sistema de arquivos Ext2 ´e um sistema confi´avel est´avel que surgiu com o prop´osito
de corrigir os erros apresentados pelo sistema proposto anteriormente, o Ext. O sistema
´e hoje usado em grande escala pelos sistemas Linux. O Ext2 ´e a principal base dos
sistemas seguintes Ext3, Ext4. Salvas algumas melhorias no Ext3 como a implementac¸˜ao
do journaling, e algumas outras mudanc¸as como a possibilidade de se ter blocos de 8KB,
seu funcionamento ´e praticamente o mesmo do Ext2, perdendo pouco em desempenho.
O sistema de arquivos Ext4, veio para solucionar o problema de enderec¸amento de 64
bits, tamb´em trouxe algumas melhorias no tempo de checagem, uso de blocos de 4KB,
e a introduc¸˜ao de um novo mecanismo de mapeamento que melhora a performance para
arquivos grande e diminiu a fragmentac¸˜ao.
References
de grupos EXT2, D. Descritor de grupos EXT2 http://www.makelinux.net/
books/ulk3/understandlk-CHP-18-SECT-2.
Dell, T. C. Tech Center Dell http://en.community.dell.com/techcenter/
high-performance-computing/w/wiki/2290.aspx.
EXT2, S. Campos Superbloco EXT2 http://pt.wikipedia.org/wiki/Ext2.
Framework, D. F. Digital Forensics http://wiki.digital-forensic.org/
index.php/Extended_File_System/.
fsck time vs. inode count. Wiki E2fsck http://en.wikipedia.org/wiki/
File:E2fsck-uninit.svg.
I-node, E. EXT2 I-node http://www.science.unitn.it/˜fiorella/
guidelinux/tlk/node96.html.
9. MinixFS at Wikipedia, t. F. E. Wikipedia http://en.wikipedia.org/wiki/
MINIX_file_system/.