You are on page 1of 47

CENTRO UNIVERSITRIO FIEO

LUCAS COSTA BEYELE

SISTEMAS DE ARQUIVOS

OSASCO
2015

CENTRO UNIVERSITRIO FIEO

LUCAS COSTA BEYELE

SISTEMAS DE ARQUIVOS

Projeto Integrado de Graduao apresentado ao


Curso de Cincia da Computao do Centro
Universitrio FIEO - UNIFIEO, como requisito
parcial obteno do grau de Bacharel em
Cincia da Computao. Orientadora: Profa.
Dra. Andreia C. G. Machion.

OSASCO
2015

AGRADECIMENTOS
Agradeo a essa universidade e seu corpo docente, que me auxiliaram ao longo dessa jornada.
A professora Andreia C. G. Machion, pelo suporte no pouco tempo que lhe coube nas correes e
incentivos.
Aos meus pais e irmo pelo amor e incentivo, e por estarem presentes em todos os momentos de minha
vida.
E a todos que fizeram parte direta e indiretamente da minha formao o meu muito obrigado.

LISTA DE FIGURAS
Figura 1: Fongrafo ........................................................................................................................ 10
Figura 2: reas de um disco ............................................................................................................ 11
Figura 3: Cabealho de um arquivo ................................................................................................. 12
Figura 4: Diretrio aberto com o editor de texto Vim ...................................................................... 14
Figura 5: Um bloco de 4KB formado por 8 setores de 512 bytes ..................................................... 14
Figura 6: Eficincia do espao em disco X Taxa de transferncia .................................................... 15
Figura 7: Exemplo de alocao contgua: ........................................................................................ 17
Figura 8: Exemplo de alocao encadeada ...................................................................................... 18
Figura 9: Exemplo da Tabela de Alocao de Arquivos .................................................................. 18
Figura 10: Um inode com os blocos de indireo ............................................................................ 19
Figura 11: Relacionamento entre as tabelas de arquivos .................................................................. 21
Figura 12: Composio de um disco com o MINIX FS ................................................................... 23
Figura 13: Exemplo do inode do MINIX FS.................................................................................... 24
Figura 14: Exemplo de um mapa de bits.......................................................................................... 24
Figura 15: Exemplo do Cache de Blocos ......................................................................................... 25
Figura 16: Composio de um disco com o EXT4 ........................................................................... 27
Figura 17: Uma rvore de extenses................................................................................................ 28
Figura 18: Composio de um disco com o NTFS ........................................................................... 31
Figura 19: Exemplo do dd aps a execuo ..................................................................................... 37
Figura 20: Criao de um nico arquivo via dd ............................................................................... 38
Figura 21: Criao de multiplos arquivos via dd (1 MB) ................................................................. 39
Figura 22:Criao de multiplos arquivos via dd (10 MB) ................................................................ 40
Figura 23: Criao de multiplos arquivos via dd (100 MB) ............................................................. 40
Figura 24: Criao de multiplos arquivos via dd (1GB) ................................................................... 41

LISTA DE TABELAS
Tabela 1: Cronograma do trabalho .................................................................................................... 9
Tabela 2: Lista de extenses e assinaturas comuns .......................................................................... 13
Tabela 3: Setores do MBR .............................................................................................................. 16
Tabela 4: Layout bsico de uma tabela GUID ................................................................................. 16
Tabela 5: Sistemas de arquivos e seus nmeros mgicos ................................................................. 17
Tabela 6: Algumas mensagens do sistema de arquivos .................................................................... 22
Tabela 7: Contedo do cabealho das extenses .............................................................................. 28
Tabela 8: Contedo dos ns das extenses ...................................................................................... 28
Tabela 9: Contedo das folhas das extenses .................................................................................. 28
Tabela 10: Tabela de inodes reservadas........................................................................................... 29
Tabela 11: Alguns campos do superbloco do EXT4 ........................................................................ 29
Tabela 12: Valores padro do tamanho do cluster do NTFS ............................................................ 31
Tabela 13: Bloco de parmetros da BIOS ........................................................................................ 32
Tabela 14: Entradas Reservadas para o MFT ................................................................................... 33
Tabela 15: Atributos do MFT .......................................................................................................... 34

SUMRIO
1. Introduo ..................................................................................................................................... 8
1.1 Objetivo Geral ......................................................................................................................... 8
1.2 Objetivos Especficos .............................................................................................................. 8
1.3 Justificativa ............................................................................................................................. 8
1.4 Metodologia ............................................................................................................................ 9
2. Fundamentao Terica .............................................................................................................. 10
2.1 Dispositivo de Armazenamento ............................................................................................. 10
2.2 Disco Rgido ......................................................................................................................... 10
2.3 Sistemas de Arquivos ............................................................................................................ 11
2.3.1 Estrutura Bsica .............................................................................................................. 12
2.3.2 Estrutura Interna.............................................................................................................. 14
2.4 MINIX File System ............................................................................................................... 23
2.4.1 Estrutura de Dados do MINIX File System ..................................................................... 23
2.4.2 Peculiaridades Encontradas ............................................................................................. 25
2.5 Fourth Extended File System (EXT4) .................................................................................... 26
2.5.1 Estrutura de Dados do EXT4 ........................................................................................... 26
2.5.2 Peculiaridades Encontradas ............................................................................................. 30
2.6 New Technology File System (NTFS) ................................................................................... 31
2.6.1 Estrutura de Dados do NTFS ........................................................................................... 31
2.6.2 Peculiaridades Encontradas ............................................................................................. 34
3. Ferramentas De Testes ................................................................................................................ 36
3.1 MINIX 3 ............................................................................................................................... 36
3.2 Ubuntu Server ....................................................................................................................... 36
3.3 Microsoft Windows 10 Pro .................................................................................................... 36
3.4 Dataset Definition dd .......................................................................................................... 36
3.5 Vmware Workstation............................................................................................................. 37
4. Realizaes de Testes.................................................................................................................. 38
4.1 Teste de Carga ....................................................................................................................... 38
4.1.1 Criao de um nico Arquivo ......................................................................................... 38
4.1.2 Criao de Mltiplos Arquivos (1 MB) ........................................................................... 38
4.1.3 Criao de Mltiplos Arquivos (10 MB) ......................................................................... 39
4.1.4 Criao de Mltiplos Arquivos (100 MB)........................................................................ 40
4.1.5 Criao de Mltiplos Arquivos (1 GB) ............................................................................ 41
4.1.6 Concluses ...................................................................................................................... 41
4.2 Uso do Sistema de Arquivos .................................................................................................. 41
4.2.1 MINIX Fs V3 .................................................................................................................. 42
4.2.2 Fourth Extended File System (EXTt4)............................................................................. 42
4.2.3 New Technology File System (NTFS) ............................................................................. 42
5. Consideraes Finais................................................................................................................... 44

6. Lista de Abreviaes ................................................................................................................... 45


7. Referncias ................................................................................................................................. 46

1. INTRODUO
A cada dia, quantidades enormes de informao so geradas, e cada vez mais tem-se a
necessidade de armazen-las e restaur-las com velocidade e facilidade. Para isso so utilizados
algoritmos e tcnicas eficientes que permitam armazenar e recuperar informaes, a que surge a
necessidade dos Sistemas de Arquivos.
Um sistema de arquivos a estrutura usada pelo computador para organizar dados em um
disco rgido. (MICROSOFT, 2015)
O tempo foi passando e o volume de dados gerados e a capacidade dos dispositivos de
armazenamento foi aumentando, forando os arquitetos de sistemas de arquivos a criarem novas
maneiras de armazenar e recuperar dados. Atualmente existem sistemas de arquivos que podem
trabalhar melhor em determinadas situaes que outros:

Os voltados para gerenciamento de elementos do sistema operacional e do hardware


como se fossem arquivos (procfs, sysfs, devfs, initramfs);
Os voltados para armazenamento de dados em disco local (EXT4, ReiserFS, NTFS,
MINIX V3 FS);
Os voltados para armazenamento distribudo (CEPH, GlusterFS);

Este trabalho possui como objetivo apresentar trs sistemas de arquivos e suas arquiteturas,
executar testes para anlise de comportamento, e ento apresentar as concluses em relao ao que foi
encontrado nesses experimentos.
1.1 OBJETIVO GERAL
Realizar um estudo sobre como os dados so gerenciados por trs sistemas de arquivos
populares: MINIX V3 FS, Fourth Extended File System (EXT4) e o New Technology File System
(NTFS), para compreenso do seu funcionamento.
1.2 OBJETIVOS ESPECFICOS
A fim de cumprir o objetivo geral deste estudo, tem-se os seguintes objetivos especficos:

Estudo do funcionamento bsico de um sistema de arquivos, analisando suas


funcionalidades;
Mapeamento da estrutura do MINIX FS, EXT4 e NTFS para anlise;
Testes para anlise de comportamento dos sistemas de arquivos, principalmente
quando colocados sob presso;
Desenvolvimento da documentao, apresentando concluses obtidas a partir dos
estudos;
1.3 JUSTIFICATIVA

O MINIX FS um sistema de arquivos gratuito e com cdigo fonte aberto desenvolvido


por Andrew Stuart Tanenbaum como parte do sistema operacional MINIX (TANENBAUM &
WOODHULL, Sistemas Operacionais: Projeto e Implementao, 2008), sendo que se encontra
atualmente em sua terceira verso. O EXT4 trata-se de um dos sistemas de arquivos mais utilizados

atualmente, que tambm de cdigo aberto e desenvolvido por uma enorme comunidade, sendo
encontrado como default de diversas distribuies UNIX-like (CALLEJA, 2008). O NTFS o mais
recente sistema de arquivos da Microsoft, de cdigo fechado e utilizado por diversos computadores
com sistemas operacionais baseados na arquitetura Windows NT, desde aqueles focados para desktop
at aqueles focados em servidores (JUNIOR, 2015) .Por essas caractersticas, os trs se apresentam
como ferramentas ideais para o estudo sobre sistema de arquivos.
1.4 METODOLOGIA
O desenvolvimento deste trabalho deve seguir os passos descritos a seguir de acordo com
o cronograma mostrado na Tabela 1.

Embasamento terico: Ser realizado um estudo aprofundado sobre o tema,


empregando tcnicas de engenharia reversa no sistema de arquivos (somente nos de
cdigo aberto) e pesquisa em materiais tcnicos disponibilizados pelos
desenvolvedores;
Execuo de testes: Sero efetuados testes de carga a fim de analisar o desempenho
do disco com determinado sistema de arquivo;
Concluses: A ltima etapa ser escrever a documentao incluindo os resultados
obtidos durante os testes;
Tarefas

Embasamento Terico
Execuo de Testes
Concluses

Tabela 1: Cronograma do trabalho


Agosto
x

Setembro

Outubro

Novembro

10

2. FUNDAMENTAO TERICA
Neste captulo ser tratado sobre dispositivos de armazenamento, em especfico o disco
rgido, o que so sistemas de arquivos, detalhando suas arquiteturas tcnicas e lgicas. Tambm so
descritas as arquiteturas do MINIX FS (TANENBAUM & WOODHULL, 2008), NTFS (TECHNET,
2003), e o EXT4 (CALLEJA, 2008).
Figura 1: Fongrafo

Fonte: (BRUDERHOFER, 2006)


2.1 DISPOSITIVO DE ARMAZENAMENTO
Dispositivo de armazenamento um meio utilizado para armazenar informaes para
consulta posterior. Esse meio de armazenamento pode variar desde uma agenda at uma estrutura mais
complexa, como um Pen Drive.
Mesmo nos meios da tecnologia as tcnicas de armazenamento no so algo recente, sendo
o fongrafo, uma inveno de Thomas Edson, o primeiro meio de armazenamento mecnico que se
tem registro. Para armazenar algum tipo de melodia, o fongrafo utiliza uma espcie de cilindro para
armazenamento, aonde uma agulha teria a tarefa de riscar as vibraes causadas pelo udio em sulcos
cobertos por uma folha de estanho (STROSS, 2010).
2.2 DISCO RGIDO
De acordo com Morimoto (2007), disco rgido um sistema de armazenamento de alta
capacidade, que por no ser voltil, destinado ao armazenamento de arquivos e programas.
Internamente ele formado por uma estrutura de discos magnticos aonde sero armazenados os
dados, e o cabeote que possui uma pequena agulha que ter a tarefa de gravar e/ou buscar os dados
dentro do disco.
A atividade de localizar dados dentro do disco chamada de seek (buscar em ingls), e a
busca dos dados sempre realizada de forma sequencial: para ler um determinado setor, a agulha
dever viajar todos os n blocos que esto entre a posio atual dela at o setor desejado. Alguns
momentos pode ser que voc tenha sorte e o setor a ser lido exatamente aquele aonde a agulha se
encontra, gerando um seek time de 0 segundos.

11

Figura 2: reas de um disco

Fonte: (MISTWIZ, 2008)


Um disco subdivido em vrias partes conforme a Figura 2, porm as mais relevantes ao
sistema de arquivos so:

Setores: a menor unidade do disco rgido, possua tamanho de at 512 bytes em


unidades antigas, porm atualmente, graas ao Advanced Format1, pode possuir o
tamanho de 4096 bytes. Nem todos os componentes do computador se utilizaro dessa
unidade, optando pela unidade de blocos, a qual ser vista posteriormente;
Trilhas: as trilhas possuem tamanhos variados, mas a forma sempre a mesma: um
crculo concntrico que comea no fim do disco e vai diminuindo de tamanho
conforme se aproximam do centro;
Cilindro: os cilindros so conjuntos de trilhas que possuem a mesma numerao e
que estejam em faces de disco diferentes;
2.3 SISTEMAS DE ARQUIVOS

Um sistema de arquivos nada mais do que uma estrutura usada pelo computador para
organizar dados em uma unidade de armazenamento. Para entender melhor, vamos utilizar como
exemplo uma biblioteca, onde os livros seriam os arquivos salvos dentro de um disco rgido. Todos os
livros, antes de serem colocados na estante so catalogados numa base de dados, que armazena
informaes como nomes dos livros, localizao deles nas estantes, data de compra, histrico de
pessoas que acessaram o livro, entre outros.
Um sistema de arquivos no muito diferente: todos os arquivos criados numa mquina
possuem suas informaes salvas dentro de uma tabela (Tabela de Alocao de Dados ou uma Tabela
de Inodes dependendo da arquitetura) que sero utilizadas posteriormente para recuperao do arquivo.
Conforme dito por Tanenbaum (TANENBAUM & WOODHULL, 2008), o
armazenamento de informaes deve respeitar as seguintes regras:

Deve ser possvel armazenar um volume muito grande de informaes;


As informaes devem sobreviver ao trmino do processo que as esto utilizando;

Advanced Format: Termo cunhado pela IDEMA que utilizado em todos os discos rgidos que foram formatados
utilizado setores maiores que 512 bytes, sendo o mais comum o 4K (4096 bytes ou 4kb) (IDEMA, 2011);

12

Vrios processos devem ser capazes de acessar as informaes concomitantemente;

2.3.1 ESTRUTURA BSICA


Neste tpico sero tratadas sobre as partes bsicas da estrutura, como arquivos e seus formatos,
diretrios e suas divises.
ARQUIVOS
Os arquivos so um mecanismo de abstrao. Eles proporcionam uma maneira de
armazenar informaes no disco e de l-las posteriormente. Isso deve ser feito de modo a esconder do
usurio os detalhes sobre como e onde as informaes so armazenadas e como os discos realmente
funcionam (TANENBAUM & WOODHULL, 2008).
Figura 3: Cabealho de um arquivo

Para auxiliar nessa abstrao de dados, o sistema de arquivos permite que um nome e uma
extenso sejam colocados no arquivo, assim o usurio poder saber do que se trata o contedo do
arquivo e tambm poder ser lembrado que programa deve ser utilizado para ter acesso ao contedo.
A quantidade de caracteres disponveis para o nome varia de sistema de arquivos para outro, tambm
quais caracteres so vlidos como nome de arquivo. J para a extenso so disponibilizados somente
3 caracteres com exceo do ponto (.).
FORMATO DE ARQUIVOS
De forma genrica, o sistema de arquivos possui somente dois formatos para arquivos:

Arquivos de Texto: onde o contedo escrito e lido no estado em que se encontra,


sem possuir nenhum caractere especial com exceo do EOF (End of File 2);
Arquivos Binrios: onde o contedo possui algum tipo de formatao especial que o
impede de ser lido por outros processos que no sejam aquele que o gerou;

End of file: A constante EOF utilizada como valor retornado por diversas funes para indicar que o final do arquivo
chegou, ou tambm falhas sobre certas condies. O caractere 1A (Ctrl - Z) era utilizado no final dos arquivos para
sistemas operacionais antigos, com o CP/M ou o DOS. Atualmente o caractere est em desuso, j que o sistema de
arquivos controla a quantidade de blocos/clusters (BUTTERWORTH, 2012)

13

Db

Extenso

Png

Xlsx

Tabela 2: Lista de extenses e assinaturas comuns

Assinatura
53 51 4C 69 74 65 20 66 6F
72 6D 61 74 20 33 00
89 50 4E 47 0D 0A 1A 0A

50 4B 03 04 14 00 06 00

Odt
Tar

50 4B 03 04
75 73 74 61 72

Significado

Arquivo de banco do SQLite

Arquivo de imagem PNG


Planilha eletrnica escrita no Microsoft Excel
2007 em diante
Arquivo de texto escrito no Libre Office Writer
Arquivo tar empacotado

Para o usurio e o sistema de arquivos isso no ajuda muito, pois fica difcil identificar
qual foi o processo que o gerou ou do que se trata seu contedo. Para solucionar esse problema foram
criados dois modelos: o primeiro onde a identificao do arquivo fica por conta de o sistema
operacional reconhecer sua extenso, e a outra o reconhecimento feito pelo sistema de arquivos
utilizando uma assinatura no cabealho do arquivo. A Tabela 2 mostra alguns exemplos para
extenses de arquivos e assinaturas de arquivos, enquanto a Figura 3 demonstra como um arquivo
salvo em disco. Note na figura o campo marcado em verde: essa a assinatura do arquivo, que de
acordo com a tabela abaixo se trata de um arquivo de texto do Libre Office.
A diferena entre um modelo e outro que, utilizando a assinatura, voc garante que est
abrindo o arquivo com a ferramenta correta. Neste caso a extenso se torna um lembrete para o usurio
do que se trata aquele arquivo.
NOME DE ARQUIVOS
A atribuio de nomes a um arquivo, conforme j dito, varia de um sistema de arquivos
para outro. Os valores que devem ser levados em conta na escolha do nome sempre so:

Tamanho do nome: Alguns sistemas de arquivo permitem 16 caracteres somente


como nome do arquivo (MINIX File System V2), enquanto outros permitem at 255
(NTFS);
Caracteres disponveis: Alguns sistemas de arquivos utilizam o padro UTF-16
(FAT), enquanto outros no aceitam o caractere ponto (EXT);
Case-sensitive: Algo como sensvel ao tamanho das letras, um sistema casesensitive identifica que um arquivo chamado OLAMUNDO.txt no possui o mesmo
nome que olamundo.txt (NTFS);

Informaes como essas precisam ser levadas em conta quando voc precisa transferir os
dados de um sistema de arquivos para outro. Em alguns casos, o dado ser impedido de ser gravado
por possuir alguma caracterstica que o destino no sabe tratar, ou o destino pode tentar tratar de tal
peculiaridade apresentando algumas possibilidades de correo para o usurio.
DIRETRIOS
Diretrios, ficheiros, ou pastas, so trs nomes diferentes para a mesma funo: criar uma
camada de abstrao que auxilie um usurio ou processo a organizar seus dados de uma forma que

14

possam ser facilmente localizados. Isso necessrio pois a maneira do sistema de arquivos localizar
dados dentro de um disco por meio de seu endereo armazenado dentro de uma tabela.
A parte a questo de organizao de arquivos, diretrios tambm so uma forma de diviso
das tabelas de localizao de dados para alguns sistemas de arquivos. Em vez de percorrer uma tabela
gigantesca, fica mais rpido varrer tabelas menores, sendo que essas tabelas menores possuiriam como
identificador um nome (no caso o nome do diretrio) e duas entradas obrigatrias: a do diretrio acima
e sua prpria entrada.
Figura 4: Diretrio aberto com o editor de texto Vim

Em alguns casos o diretrio somente outro arquivo, um de texto no caso, sendo possvel
ler seu contedo com qualquer editor de texto (e.g. Vim, Vi ou GNU nano), como pode ser visto na
Figura 4. O roxo indica que se trata de um arquivo oculto 3, o azul so outros diretrios, e os brancos
so arquivos de texto ou outro contedo qualquer que seja visvel ao usurio.
2.3.2 ESTRUTURA INTERNA
Aqui veremos a estrutura tcnica de um sistema de arquivos, como o esquema de alocao
de dados, bloco de boot, e superbloco.
BLOCO OU CLUSTER
512 bytes

Figura 5: Um bloco de 4KB formado por 8 setores de 512 bytes

512 bytes

512 bytes

512 bytes 512 bytes


BLOCO DE 4K

512 bytes

512 bytes

512 bytes

Bloco ou cluster, como chamado em sistemas da Microsoft (TECHNET, 2003), a menor


unidade do sistema de arquivos: trata-se de uma regio no disco que possui tamanho X KB e serve
para armazenar e recuperar partes de um dado. O tamanho do bloco pode variar e depende da
Em alguns sistemas operacionais, colocar o ponto no incio do nome do arquivo significa que ele oculto, como por
exemplo o UNIX. Outros, como o Windows, tratam a ocultao do arquivo como um atributo;
3

15

disponibilidade do sistema de arquivos, sendo os valores mais comuns de 1kb a 8 KB (4 KB o default


de muitos sistemas de arquivos, alm de um valor que atende quase todas as necessidades).
Um bloco sempre ser exclusivo ao dado que est armazenado nele, mesmo que ainda
possua espao para armazenar mais coisas dentro dele. Isso ocorre porque o sistema de arquivos
controla um bloco inteiro, e no somente parte dele. Sendo assim problemas de controle e at permisso
seriam frequentes, e para solucion-los seria necessrio um trabalho desnecessrio do processador em
troca de um pouco mais de espao.
O tamanho do bloco interfere no seek time 4 e na quantidade de arquivos que podem ser
armazenados. Na Figura 6 possvel ver que quanto maior for o bloco menor ser o seek time, e
tambm menor ser a quantidade de arquivos que podero ser armazenados. Caso os blocos sejam
pequenos, o seek time ser maior pois o arquivo possuir mais fragmentos, porm ser possvel
armazenar mais arquivos em disco.
Figura 6: Eficincia do espao em disco X Taxa de transferncia
100

Taxa de dados (KB/s)

1000

80

800

60

600

40

400

20

200
0

Utilizao do Espao em disco (porcentagem)

1200

128 B

256 B

512 B

1 KB
2 KB
4 KB
Tamanho do bloco (bytes)

Utilizao do Espao em Disco

8 KB

16 KB

Taxa de Transferncia de Dados

BLOCO DE BOOT
Bloco de boot a primeira rea do disco, que possui tamanho mximo de 1024 bytes (2
setores), e que responsvel por inicializar o contedo do disco durante o arranque do computador,
por exemplo o Sistema Operacional. Em seu contedo pode ser encontrado um nmero mgico
informando se a partio inicializvel ou no, e o cdigo que ser responsvel pela inicializao do
sistema (um bootloader).
O acionamento do bloco de boot pode ser feito de duas maneiras: atravs do Registro
Mestre de Inicializao (MBR) ou atravs da Tabela de Partio GUID (GPT).

Seek time: indica o tempo que a cabea de leitura demora para ir de uma trilha outra do disco, ou seja, indica a
performance da agulha usada no HD (MORIMOTO, 2007);
4

16

REGISTRO MESTRE DE INICIALIZAO (MBR)


O MBR ainda hoje o modelo mais utilizado para gerenciamento de boot de um disco.
Feito para trabalhar em conjunto com o Sistema Bsico de Entrada/Sada (BIOS), o MBR fica
localizado no incio do disco e possui tamanho mximo de 512 bytes, disponibilizados conforme a
Tabela 3 (TECHNET, 2015).
Endereo
+000h
+1BEh
+1CEh
+1DEh
+1EEh
+1FEh ou +1FFh

Tabela 3: Setores do MBR

Descrio
Cdigo de Bootstrap
Entrada da Partio 1
Entrada da Partio 2
Entrada da Partio 3
Entrada da Partio 4
Assinatura de boot do disco

Tamanho (em bytes)


446
16
16
16
16
2

O MBR possui capacidade de gerenciar 4 parties primrias com at 2 TB, e no possui


redundncia. Com a substituio da BIOS pela Interface Unificada de Firmware Extensvel (UEFI) o
MBR comea a perder espao para a GPT, porm ainda mantido por questes de compatibilidade.
Tabela 4: Layout bsico de uma tabela GUID

Layout Bsico de uma Tabela de Partio GUID


Master Boot Code
Entrada 1 da Tabela de Partio
Entrada 2 da Tabela de Partio
MBR PROTETIVA
Entrada 3 da Tabela da Partio
Entrada 4 da Tabela da Partio
Cabealho da Tabela de Partio GUID
Entrada 1 da Partio GUID
Entrada 2 da Partio GUID
TABELA DE PARTIO GUID
Entrada n da Partio GUID
Entrada 128 da Partio GUID
Partio Primria (C:)
Partio Primria (D:)
PARTIES CRIADAS NO DISCO
Partio Primria n
Entrada 1 da Partio GUID
Entrada 2 da Partio GUID
BACKUP DA TABELA DE
PARTIO GUID
Entrada n da Partio GUID
Entrada 128 da Partio GUID
Backup Cabealho da Tabela de Partio GUID
TABELA DE PARTIO GUID (GPT)
Com o aumento dos discos, foi necessrio criar um modelo de gerenciamento de arranque
da mquina, e que fosse totalmente compatvel com a Interface Unificada de Firmware Extensvel
(UEFI). Foi com esse intuito que surgiu a Tabela de Partio GUID (GPT), permitindo at 128

17

parties (dependendo do tamanho da GPT), contadores de setores de 64 bits (maior partio de 9,4
ZB), e redundncia (a GPT pode ser encontrada no incio e no final do disco).
A Tabela 4 ilustra um disco que utiliza o GPT. Mesmo no sendo mais necessrio, o MBR
ainda est presente num disco por motivos de compatibilidade, sendo o incio do GPT fica no bloco
adjacente, e ao final do disco uma cpia de seus dados so mantidas em caso de ocorrer alguma falha
o incio do disco.
SUPERBLOCO OU BLOCOS DE PARMETROS DA BIOS
Superbloco, ou bloco de parmetros da BIOS (BPB) como chamado na documentao
da Microsoft, a primeira rea do disco relacionada ao sistema de arquivos. Este bloco serve para
armazenar algumas informaes relacionadas ao sistema de arquivos da partio a qual ele pertence,
como o nmero mgico, que contm um valor (em hexa) que informa ao sistema operacional qual o
sistema de arquivos que deve ser utilizado para a montagem da partio. A Tabela 5 mostra alguns
desses nmeros mgicos.
Alguns sistemas de arquivos mais recentes, como o MINIX File System no possuem todos
os dados do superbloco gravados em disco, j que vrios deles so volteis (exemplo a primeira inode
livre, tamanho em disco, flag de somente-leitura, e verso do sistema de arquivos). Isso feito como
forma de proteo contra m escrita, pois um superbloco danificado acaba inutilizando toda a partio.
Tabela 5: Sistemas de arquivos e seus nmeros mgicos

0xEF53
0x5346544E
0x4D5A
0x3153464A
0x4D44
0x9123683E

Nmero Mgico

Sistema de arquivos
Extended File System (EXT)
New Technology File System (NTFS)
MINIX File System V3
Journaling File System (JFS)
Sistema de Arquivos MSDOS
Better File System (Btrfs)

ESQUEMA DE ALOCAO DE DADOS


Alocar dados dentro de um disco no uma tarefa fcil, muito menos manter essa alocao
com o passar do tempo. Existem atualmente trs tcnicas bastante comuns utilizadas por sistemas de
arquivos: alocao contgua, alocao encadeada e os inodes.
0x55
PART 1
(Begin)

0x56
PART 2

Figura 7: Exemplo de alocao contgua:


0x57
0x58
0x59
0x60
PART 3
PART 4
PART 5
PART 1
(EOF)
(Begin)

0x61
PART 2

0x62
PART 3
(EOF)

A alocao contgua faz com que um arquivo salvo em disco tenha seus blocos
armazenados de forma que todos estejam prximos. Isso diminui a quantidade de chamadas de seek
que o sistema teria que fazer para ter acesso a todo o arquivo. Em unidades de disco de gravao nica
(como o CD ou o DVD) este tipo de gravao efetivo, pois, voc garante que os arquivos jamais se
fragmentaro, porm em dispositivos de armazenamento onde voc tem certeza que os dados sero
volteis em um certo ponto, mais cedo ou mais tarde os dados se fragmentaro ou se perdero.

18

0x55
Begin
NEXT:
0x56

0x56
NEXT:
0x61

Figura 8: Exemplo de alocao encadeada

0x57
Begin
NEXT:
0x62

0x58
EOF

0x59
NEXT:
0x60

0x60
EOF

0x61
NEXT:
0x58

0x62
NEXT:
0x59

Na alocao encadeada continua possui a mesma ideia da alocao contgua: dados sero
armazenados de forma contgua, porm todos possuiro informao da localizao do prximo bloco
adjacente. A diferena que, caso a partio fragmente, os dados ainda sim sero acessveis, por outro
lado existe uma perda enorme de desempenho pois quando um processo l um bloco ele no precisa
do cabealho, obrigando o sistema de arquivos a concatenar os blocos.
Figura 9: Exemplo da Tabela de Alocao de Arquivos

Uma soluo apresentada a que encontramos hoje nos sistemas de arquivos FAT: uma
tabela de alocao de dados que possui a localizao de todos os arquivos em um nico lugar. Dessa
maneira o sistema de arquivos no precisa mais concatenar os dados antes de repassar para o processo.
Porm a FAT obriga que a tabela inteira esteja na memria o tempo todo, o que pode ser um problema
dependendo do tamanho do disco, a quantidade de arquivos presentes nele e o quanto de memria voc
tem disponvel para uso.
Para solucionar o fato de manter a tabela todo o tempo na memria foram desenvolvidos
os inodes, hoje utilizados por quase todos os sistemas de arquivos populares do Linux. Neste modelo,
existe uma tabela na memria que armazena somente as entradas dos arquivos em uso no momento.
Caso o arquivo seja fechado, a entrada expurgada da memria, limitando a tabela somente ao limite
mximo de arquivos que podem ser abertos simultaneamente pelo sistema operacional.
Com os inodes, alm dos problemas de desempenhos causados ao seek time, um novo
problema surge: a impossibilidade de se criar arquivos muito grandes. Um inode disponibiliza at sete
blocos, numerados de 0 a 6, para armazenamento de dados, porm caso precise de mais espao so
disponibilizados mais trs blocos para uso de blocos de indireo.
Blocos de indireo so formados por um inode separado que possui X blocos, sendo X
quem define o sistema de arquivos. O primeiro bloco de indireo possui seu endereo no bloco 7, e
caso seja preciso mais blocos disponveis para este arquivo so utilizados os blocos de indireo dupla,
que so X blocos que gerenciam X blocos cada. E se mesmo assim for preciso mais blocos, alguns

19

sistemas de arquivos disponibilizam os blocos de indireo tripla, onde so X blocos que gerenciam X
blocos que gerenciam X blocos cada.
A Figura 10 demonstra melhor como funcionam esses blocos de indireo. Porm, aps o
uso de blocos de indireo tripla, o inode considerado cheio, e um arquivo que utiliza mais do que
um inode consegue gerenciar considerado como muito grande e ento descartado. Uma soluo seria
aumentar o nmero de blocos de indireo, porm no s no vantajoso, como tambm esbarra no
limite de ponteiros do sistema operacional.
Um sistema operacional 32 bits consegue gerenciar 2-1 ponteiros, isso caso sejam
5
unsigned . Por conta desta limitao, durante muito tempo foi impossvel gerar arquivos maiores que
4GB. A soluo veio muito depois com o Large File Support (LFS), um conjunto de alteraes feitas
no kernel do Linux e na linguagem de programao C que permitem emular ponteiros de 64 bits. Com
isso o problema foi postergado, j que com ponteiros 64 bits o maior arquivo que pode ser criado de
16 GB.
Figura 10: Um inode com os blocos de indireo

Fonte: (CARD, TS'O, & TWEEDIE, 2015)


Um problema que afeta todos os sistemas de arquivos a incapacidade de manter os dados
de forma sequencial. Normalmente, durante o processo de gravao de dados em disco, blocos so
disponibilizados de forma sequencial a partir do incio do disco com o intuito de diminuir o seek time,
porm caso exista escrita/excluso de dados com muita frequncia no dispositivo, possvel que eles
comecem a ficar esparsos na unidade, o que chamado fragmentao de disco. Com o passar do tempo
isso acarreta uma perda de desempenho, pois para um disco rgido mais vantajoso ler blocos
sequenciais do que ficar caando seus fragmentos. Para evitar este cenrio alguns sistemas de arquivos
possuem um ou mais mtodos de alocao de blocos anti-fragmentao, sendo os mais conhecidos:
mballoc, fallocate e delalloc.
A Alocao de Multiblocos (mballoc), presente no EXT2 em diante, especula que pelo
menos 8KiB sero gravados em discos, ento reservar estes blocos para o arquivo. Caso estes blocos

Unsigned: Varivel do tipo numrica sem sinal (RODRIGUES, 2013)

20

no sejam realmente utilizados aps o fechamento do arquivo, ento estes 8KiB sero devolvidos como
disponveis para a prxima requisio.
A Pr-Alocao (fallocate), presente no EXT3 e EXT4, somente inicia o processo de
gravao aps todos os blocos estarem reservados em disco. Quando se cria um novo arquivo, o
sistema de arquivos ter que verificar se existe blocos o suficiente para a solicitao. Se existir ento
eles so reservados e se d o incio da gravao. A pr-alocao no interfere com o tempo de escrita,
j que no posterga a gravao.
J a Alocao com Atraso (delalloc), ou Alocao Durante o Flush, o mtodo menos
utilizado deles por ser o mais recente. Atualmente encontrado no XFS, Btrfs, e no EXT4, este mtodo
atrasa a gravao dos dados ao mximo possvel, ao contrrio do que encontrado tradicionalmente
que gravar os dados o mais cedo possvel (CALLEJA, 2011). Quando voc atrasa a alocao dos
blocos voc acaba tirando a vantagem de conseguir armazenar da melhor forma possvel arquivos cujo
os dados esto em constate crescimento, alm de evitar que arquivos temporrios sejam escritos em
disco. O tempo que se leva antes de iniciar a gravao definido por trs fatores:

O valor definido no campo commit_timeout durante a formatao (default 5


segundos);
Se o computador ficou com memria insuficiente durante a gravao do arquivo em
cache;
Se a chamada sync () foi acionada pelo sistema de arquivos (normalmente acionada
entre 30 a 60 segundos);

TABELA DE DESCRITORES DE ARQUIVOS


Com o crescimento das memrias RAM, o sistema operacional junto ao sistema de
arquivos passou a possuir mecanismos que evitam o uso do disco devido a velocidade de leitura de
seus dados. Um desses mecanismos um conjunto de tabelas gerenciadas pelo sistema operacional e
o sistema de arquivos para informar quais so os arquivos que esto abertos e quais processos esto
utilizando eles.
A primeira tabela a Tabela de Inodes Abertas, na qual uma tabela que fica na memria
e armazena os inodes de todos os arquivos que esto abertos. Esta tabela possui o tamanho igual ao
nmero de arquivos que podem ser abertos simultaneamente em disco. Cada entrada nica, ou seja,
o inode daquele determinado arquivo s ser adicionado a tabela uma nica vez. Um campo de
contador utilizado para definir quantos processos ainda esto utilizando. Quando este contador atinge
0, ento a entrada expurgada da memria.
A segunda tabela a Tabela de Arquivos Abertos, ou Tabela FILP como descrito por
Tanenbaum (TANENBAUM & WOODHULL, Sistemas Operacionais: Projeto e Implementao,
2008). Esta tabela possui como entrada o modo em que o arquivo foi aberto e o ltimo bloco lido. Esta
tabela possui relacionamento com a Tabela de Inodes Abertas, sendo que 1 ou mais entradas podem
ser direcionadas para o mesmo arquivo, porm com permisses diferentes e blocos diferentes.
Por ltimo vem a Tabela de Descritores de Arquivos, que nada mais que um vetor
contendo valores para que o processo consiga se localizar dentro da Tabela de Arquivos Abertos. De
acordo com a documentao do Linux (MAN, 2001), como padro as entradas 0, 1 e 2 so sempre
reservados para os arquivos de fluxos de entrada/sada padro do sistema:

STDIN: Entrada padro de dados, representado pelo descritor 0 sempre;


STDOUT: Sada padro de dados, representado pelo descritor 1 sempre;
STDERR: Sada padro de erro, representado pelo descritor 2 sempre;

21

As entradas da tabela de descritor podem ser compartilhadas entre o processo de origem e


aqueles que foram gerados por ele, dessa forma permitindo que processos compartilhem entre si
determinados arquivos para uso.
Figura 11: Relacionamento entre as tabelas de arquivos

Fonte: (WOLSKI, 2014)


MENSAGENS
J vimos anteriormente sobre a chamada seek, a qual responsvel por executar uma busca
em disco para encontrar o prximo bloco do arquivo que est sendo lido no momento. Mensagens so
a maneira que o sistema de arquivos utiliza para se comunicar entre um processo solicitante e seus
mtodos. De acordo com Tanenbaum (TANENBAUM & WOODHULL, 2008):
A estrutura do sistema de arquivos basicamente a mesma do gerenciador de
processos e de todos os drivers de dispositivos de E/S. Ela tem um lao principal que espera a
chegada de uma mensagem. Quando chega uma mensagem, seu tipo extrado e usado como
ndice em uma tabela contendo ponteiros para as funes dentro do sistema de arquivos que
as manipulam. Ento, a funo apropriada chamada, faz seu trabalho e retorna um valor de
status. O sistema de arquivos envia, ento, uma resposta para o processo que fez a chamada e
volta para o incio do lao para esperar a prxima mensagem.

interessante lembrar que um processo pode ficar horas parado enquanto aguarda uma
resposta do sistema de arquivos, j que esta foi a forma que os projetistas encontraram para deixar um
processo em modo de espera. Mandar uma requisio para o sistema de arquivos no significa que ela
ser atendida na hora, e sim que ser enfileirada e posteriormente tratada quando for mais conveniente.
No responder a requisio tambm no significa que o sistema de arquivos ficar parado
o tempo todo at conseguir a resposta do programa: o sistema anota quem foi o solicitante, qual foi a
requisio e a enfileira, para ento se libera para aguardar a prxima chamada.

22

Mensagens
chdir
chmod
chown
creat
seek
rename
sync

umount
mount
mknod
revive
read
write
rmdir
setuid
setgid
close

Tabela 6: Algumas mensagens do sistema de arquivos

Descrio
Altera o diretrio de trabalho
Altera as permisses do arquivo/diretrio
Altera o usurio/grupo dono do arquivo
Cria um novo arquivo em disco
Busca pelo prximo bloco do arquivo no disco
Renomeia o arquivo/diretrio
Grava todos os blocos alterados que esto em
cache
Desmonta uma partio
Monta uma partio
Cria um arquivo especial
Revive um processo
L o contedo de um arquivo
Escreve um novo bloco ao final do arquivo
Exclui um diretrio
Seta um novo valor para o usurio dono do
arquivo
Seta um novo valor para o grupo dono do
arquivo
Fecha um arquivo e exclui a inode dele da
memria

Valor de Resposta
Status
Status
Status
Descritor do Arquivo
Nova Posio
Status
Sempre OK

Status
Status
Status
(Nenhuma resposta)
Nmero de bytes lidos
Nmero de bytes escritos
Status
Status
Status
Status

A Tabela 5 mostra algumas mensagens que so importantes, porm todas esto sujeitas a
disponibilidade do sistema de arquivos.
REGISTRO DE MUDANA (JOURNALING)
De acordo com Jones (2008), sistemas de arquivos com registro de mudanas (Journaling)
so sistemas de arquivos resistentes a falhas que usam um dirio que registra as alteraes antes que
elas sejam guardadas no sistema de arquivos para evitar que os metadados sejam corrompidos. Esses
registros so armazenados numa rea reservada pelo sistema de arquivos de at 15% do disco, e l
todas as alteraes so salvas na forma de um dirio. Caso ocorra uma falha de escrita, na prxima
montagem a ferramenta de anlise de disco do sistema operacional (fsck ou chkdsk) consultar este
jornal e desfazer todas as ltimas operaes at que o disco esteja consistente de novo.
O registro de mudanas pode operar de trs formas diferente:

Writeback Mode: Neste modo somente o metadado salvo no jornal, enquanto os


dados j so salvos diretos em suas reas reservadas. Dessa forma voc evita a
corrupo do sistema operacional, porm possui uma grande chance do arquivo que
voc criou corromper durante a escrita em disco;
Ordered Mode: Neste modo continuamos salvando somente o metadado, porm ele
s ser adicionado ao jornal aps confirmar que o arquivo foi escrito em disco. Isso
evita a corrupo dos dados alm do sistema de arquivos;
Data Mode: Considerado o modo mais seguro para ser utilizado, neste os dados e os
metadados sero gravados no jornal, e aps isso sero regravados em disco. Dessa
forma voc garante que quase nunca os dados corrompero, porm neste modo voc

23

tem uma enorme perda de desempenho, j que todo arquivo ser gravado duplamente
em disco;
2.4 MINIX FILE SYSTEM
O MINIX File System somente um grande programa em C que executa no espao do
usurio (TANENBAUM & WOODHULL, 2008), recebendo todas as requisies dos processos,
tratando e enviando para o kernel, e depois repassando a resposta novamente para o processo
solicitante. Iniciou-se como um software desenvolvido para estudos, igual a o resto do MINIX, porm
seu cdigo cresceu tanto que est mais prximo de uma ferramenta para ser utilizada no dia a dia. Para
todos os fins trataremos aqui de seu ltimo release at o momento, o V3.
Algumas das caractersticas desse sistema de arquivos so:

Exclusivamente 32 bits: Diferentemente dos demais que se comportam de formas


diferente dependendo da estrutura de dados do sistema operacional, ele foi
desenvolvido completamente para funcionar em ambientes 32 bits, j que o MINIX
no possui uma verso sua 64bits oficialmente;
Tamanho mximo de arquivo: Capacidade de armazenamento de dados de no
mximo 2 GB por arquivo, e possui como tamanho mximo de disco 4 TB;
Tolerncia a falhas: possui mecanismos que dificultam falhas durante a gravao dos
dados em disco, e tambm possui capacidade de restaurar os dados em caso de uma
eventual falha;
Suporte a nomes de arquivos longos: possui suporte de at no mximo 30 caracteres
por arquivo (sem contar os nomes dados s pastas);
Gerenciamento de arquivos com inodes: possui uma estrutura suporte a inodes,
conseguindo gerenciar blocos at duplamente indiretos dentro de um nico inode;
Segurana: O gerenciamento de permisses dos arquivos baseado no documento
POSIX6;
Figura 12: Composio de um disco com o MINIX FS

Bloco de Boot

Superbloco

MINIX FILE SYSTEM

Mapa de Inodes

Mapa de Blocos

Dados

2.4.1 ESTRUTURA DE DADOS DO MINIX FILE SYSTEM


O MINIX possui uma estrutura de dados conforme a apresentada na Figura 12, sendo que
algumas das partes j foram discutidas anteriormente (bloco de BOOT, blocos e superbloco).
I-NODE
O MINIX possui uma estrutura de inode bem semelhante a outros sistemas de arquivos do
mesmo porte, porm com limitaes conforme pode ser visto na Figura 13.

Portable Operating System Interface (POSIX): Conjunto de normas da IEEE e da Open Group que definem um sistema
operacional UNIX. (IEEE , 2008)
6

24

Figura 13: Exemplo do inode do MINIX FS

Modo
Nmero de links
Uid
Gid
Tamanho do arquivo
Data de acesso
Data de modificao
Data da modificao de status
Zona 0
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Zona 6
Zona de Indireo
Zona de Indireo Dupla
Sem uso

Uma tabela dessas possui o tamanho mximo de 64 bytes, e ela criada para cada novo
arquivo em disco. Conforme Tanenbaum (2008), essa regio foi colocada por compatibilidade as
normas da POSIX do que para algum uso do sistema operacional. Em seu cdigo fonte, o MINIX
gerencia os blocos do disco utilizando ponteiros inteiros de 32 bits signed 7, o que limita a 2 GB o
maior arquivo em disco. Isso seria o equivalente a ocupar somente at a zona de indireo dupla. Num
cenrio desses no h necessidade de mais zonas de indireo.

0x55
1

0x56
1

0x57
1

Figura 14: Exemplo de um mapa de bits

0x58
0

0x59
0

0x60
1

0x61
0

0x62
0

0x63
1

0x64
0

MAPA DE BITS
O MINIX gerencia os blocos e inodes livres utilizando duas tabelas separadas chamadas
de mapa de bits (bitmap), que pode ser visto na Figura 14. Cada uma possui uma tabela contendo a
localizao de todos os inodes ou blocos, sejam eles livres ou em uso, e utiliza isso como uma forma
de controle. Incluso e excluso de arquivos ocorre por meio da atualizao dessa tabela. Informando
que um determinado bloco desta tabela est em uso ou no mais que o suficiente para que o sistema
de arquivos saiba quais blocos disponibilizar para escrita.
Outro ponto da arquitetura que o inode 0 no existe: ao contrrio dos vetores que
comeam a partir do 0, os inodes possuem como primeiro ndice o inode 1. O 0 utilizado para
informar ao sistema de arquivos que ocorreu um erro durante a sua chamada (pesquisar por uma inode
7

Signed: Variveis do tipo numricas com sinais. (RODRIGUES, 2013)

25

X ou se existem inodes livres). Isso significa que, pelo menos, um inode no possui uso para
armazenamento no disco.
Figura 15: Exemplo do Cache de Blocos

0x55
0x56
0x57
0x58
0x59
0x60
0x61
0x62
Count: 1 Count: 2 Count: 3 Count: 3 Count: 4 Count: 6 Count: 7 Count: 7
CACHE DE BLOCOS
O cache formado por duas listas duplamente ligadas organizadas do bloco mais acessado
para o menos acessado, como pode ser visto na Figura 15. Quanto mais processos estiverem
requisitando um determinado bloco, mais prximo do final da lista ele estar. O controle de quantos
processos esto requisitando determinado bloco feito por meio de um contador. Quando este contador
chega a zero significa que no existe mais nenhum processo requisitando ele, ento o bloco pode ser
seguramente descartado do cache.
Para controlar quais blocos esto no cache utilizada uma segunda tabela a qual contm
um hash de n bits de ordem inferior do bloco cacheado. Antes de executar uma operao de seek, o
sistema de arquivos confere primeiro se o bloco j no se encontra cacheado, e somente caso no esteja
que executar uma operao de seek. Para agilizar o processo, o sistema de arquivos tambm
cachear o bloco seguinte, mesmo que no seja necessrio.
SINCRONIZANDO BLOCOS

O MINIX no grava os blocos de imediato: ao invs disso ele a salva dentro do cache para
posteriormente enviar a mensagem sync para gravar todos no disco. A chamada sync no precisa
necessariamente ser chamada de tempos em tempos para que o bloco seja salvo.
Se nenhum processo estiver utilizando um determinado bloco, antes de expurg-lo do
cache, enviada a mensagem de sync e o bloco escrito em disco. Outro momento que isso pode
ocorrer quando um processo utiliza um bloco no cache que possui contedo diferente do disco.
2.4.2 PECULIARIDADES ENCONTRADAS
A seguir so descritos alguns problemas relatados pelos usurios ou at mesmos encontrados nas
especificaes do sistema.
DESCONTINUIDADE
Conforme Tanenbaum (2010), existe um trabalho em conjunto para desenvolver um
sistema de arquivos que possua tolerncia a falhas. Como o seu cdigo fonte tambm no atualizado
no Github8 desde Dezembro de 2014 possvel perceber que o sistema de arquivos no possuir
nenhuma nova release.

Github: site de compartilhamento de projetos Open Soure privados e pblicos que permite versionamento e
colaborao (GITHUB, 2015);
8

26

CDIGO INCOMPLETO E CONFUSO


Conforme pode ser visto no cdigo fonte, e at mesmo escrito por Tanenbaum (2008), o
sistema de arquivos MINIX possui trechos de cdigo nele que no possuem uso nenhum. So partes
que foram deixadas l para posteriormente terem suas funes completadas por algum que tivesse
interesse nele.
SEM RETROCOMPATIBILIDADE
Uma dessas funes que foram deixadas incompletas justamente a compatibilidade com
verses anteriores do sistema de arquivo. Vale ressaltar que este problema no ocorre com a verso
mantida por Karel Zak no GitHub ou no repositrio da Canonical (util-linux), j que se trata de um
fork do build original (v1) (TANENBAUM & WOODHULL, 2008).
2.5 FOURTH EXTENDED FILE SYSTEM (EXT4)
Atualmente na sua quarta release, o EXTFS (CALLEJA, 2008) o sistema de arquivos
base das distribuies Linux. Lanado em 2008 por uma equipe de programadores lideradas pelo
desenvolvedor Theodore Ts'o, ele foi lanado com o intuito de ser o substituto do EXT3, que
apresentava uma srie de problemas de desempenho. um sistema de arquivos de cdigo aberto que
funciona na camada de usurio utilizando dos recursos e vantagens proporcionados pelo Virtual File
System Switch (VFS)9.
Entre as melhorias do EXT4 (DJWONG, 2014), as que podemos destacar so:

Tamanho mximo de disco: o EXT4 possui como tamanho mximo 1EiB de disco e
consegue gravar arquivos de at 16 TiB;
Gravao atrasada: para evitar a fragmentao, o EXT4 vem com a opo do
delalloc ativada por default;
Modo No-Journaling: como default o EXT4 possui ativo o sistema de Journaling,
porm possvel desativa-lo caso no exista interesse em utiliza-lo. Em sua verso
anterior (EXT3) o Journaling era obrigatrio o uso;
Suporte a Extenses: Os inodes foram alterados para abandonar o uso dos blocos de
indireo em favor das rvores de extenses, melhorando o gerenciamento dos dados
em disco;
Checksum de Metadados: Para proteger os metadados contra eventuais falhas o
EXT4 passou a armazenar uma soma de verificao em todos os seus metadados;
Modo 48bits: No momento o EXT4 no possui e no precisa de suporte a 64bits,
porm 32bits j no atendem mais as necessidades devido a limitao de criao de
arquivos (maior arquivo 32bits 4GB). Por isso, caso o sistema de arquivos tenha o
modo 64bits habilitados, sero utilizados um ponteiro 16 bits e outro 32 bits;
2.5.1 ESTRUTURA DE DADOS DO EXT4

Diferente do MINIX FS, o EXT4 possui uma estrutura de dados um pouco mais complexa
que pode ser visto na Figura 15.

Virtual File System Switch: (VFS): Uma camada de software do Kernel que trata todas as requisies de sistemas
relacionadas a Sistemas de Arquivos Unix (BOVETI & CESATI, 2002).
9

27

EXTENSES E RVORES DE EXTENSES


A primeira e maior mudana feita no EXT4 a maneira em que os blocos so armazenados
em disco: a equipe abandonou o uso dos blocos de indireo a favor de uma estrutura chamada
extenso. Extenses (extent) so formaes de dados que so armazenadas de forma contnua no disco,
conforme pode ser visto na Figura 16. Invs de voc ter que utilizar uma entrada nos blocos de
indireo para cada bloco escrito em disco, com as extenses voc s precisa de um para cada conjunto
de blocos que forem gravados de forma contnua. O resultado desta mudana que agora o EXT4
possui capacidade de armazenar dados de at 16TiB.
Figura 16: Composio de um disco com o EXT4

Superbloco
Superbloco

FOURTH EXTENDED FILE SYSTEM


Grupo 0
Descritor do
Blocos
Mapa de
Mapa de
grupo
reservados
blocos
inodes
Dados
Grupo 1
Descritor do
Blocos
Mapa de
Mapa de
grupo
reservados
blocos
inodes
Dados

Tabela de
inodes
Tabela de
inodes

Uma extenso pode armazenar o endereo de at 32768 blocos, porm nem todo esse
espao pode ser usado quando a extenso alocada para um arquivo. possvel que, por causa do
disco estar extremamente fragmentado ou o arquivo ser extremamente grande, mais extenses
precisem ser disponibilizadas. Por padro um inode do EXT4 possui 5 entradas para extenses, cada
uma de 12 bits cada (60 bits), sendo 1 como cabealho, e as outras 4 para armazenar. Caso o arquivo
venha a precisar de mais extenses ento passamos a utilizar as rvores de extenses para armazenar
estes arquivos.
rvore de Extenses so rvore b+10que armazenam extenses em suas folhas. Essa
rvore possui a profundidade mxima de 5, sendo os dados disponibilizados de acordo com a Figura
16 e as Tabelas 7, 8 e 9.
GRUPO DE BLOCOS
O EXT utiliza uma estrutura chamada de Grupo de Blocos, que se trata de um aglomerado
de 32768 blocos que agem como regies independentes, possuindo seus prprios mapas de inodes e
blocos, e uma cpia do superbloco. A ideia parecida com os cilindros: permitir que as partes de um
arquivo estejam armazenadas no mesmo local, de forma a agilizar a leitura e diminuir a fragmentao.
A partir do EXT4 esta estrutura recebeu uma nova funo, chamada de Grupo de Blocos
Flexveis, que possui a mesma ideia que o grupo de blocos normais, porm os mapas de inodes/blocos
e o superbloco estaro localizados no incio de cada grupo de bloco que seja um mltiplo de 3.

rvore B+: Um tipo de rvore B aonde os objetos ficam na folha, e a raiz serve somente para indicar a profundidade
at o momento (HARRIS, 2010);
10

28

Figura 17: Uma rvore de extenses

Fonte: (HSIUNG, 2009)

Offset
0x0
0x2
0x4
0x6
0x8
Offset
0x0
0x4
0x8
0xA
Offset
0x0
0x4
0x6
0x8

Nome
eh_magic
eh_entries
eh_max
eh_depth
eh_generator
Nome
ei_block
ei_leaf_lo
ei_leaf_hi
ei_unused
Nome
ee_block
ee_len
ee_start_hi
ee_start_lo

Tabela 7: Contedo do cabealho das extenses

Descrio
Nmero Mgico
Nmero de extenses em uso
Nmero mximo de extenses disponveis para esse inode
Profundidade dessa extenso. Valor mximo de 5
Gerao dessa rvore. Sem uso para o EXT4 no momento

Tabela 8: Contedo dos ns das extenses

Descrio
Informa o range de blocos indexados por este n
Os ltimos 32 bits que compe uma extenso
Os primeiros 16 bits que compe uma extenses
Reservado para uma futura atualizao

Tabela 9: Contedo das folhas das extenses

Descrio
O endereo do primeiro bloco armazenado nesta extenso
Nmero de blocos atendidos por essa extenso.
Os primeiros 16 bits que essa extenso aponta
Os ltimos 32 bits que essa extenso aponta

INODES
Alm da mudana dos blocos indiretos para extenses, os inodes do EXT4 tambm
passaram a ganhar alguns campos novos, sendo um deles o to aguardado ctime, ou data de criao.
O primeiro inode valido inicia a partir do 12, sendo os anteriores utilizados para gerenciamento. Eles

29

esto disponibilizados conforme apresentado na Tabela 10, ressaltando que por mais que seja dito que
a inode 11 seja o primeiro inode disponvel em disco, ainda sim j possui uma entrada por padro.
Inode
0
1
2
3
4
5
6
7
8
9
10
11

Tabela 10: Tabela de inodes reservadas

Propsito
Utilizado como mensagem de erro de Sem inode disponvel
Lista de blocos defeituosos
Diretrio root
Quota de usurio
Quota de grupo
Bootloader
Diretrio protegido contra excluso
Reservado para uso futuro
Jornal
Reservado para uso futuro
Reservado para uso futuro
Primeiro inode livre. Utilizado pela pasta lost + founds

SUPERBLOCO
Diferente de outros sistemas de arquivos, como o MINIX FS, o EXT4 permite a edio do
superbloco de forma a armazenar o maior nmero de informaes possveis dentro do espao de 1024
bytes. Isso feito de forma a evitar que toda vez os dados sejam recalculados, por outro lado existe
uma chance do superbloco ser corrompido. Como forma de segurana, o EXT4 possui uma cpia do
superbloco no incio de cada grupo de blocos presentes na partio. Caso a opo sparse_super esteja
ativa, ento o superbloco ser salvo somente em grupos que sejam multiplos de 3 (Grupo de Blocos
Flexveis).
Offset
0x0
0x4
0x20
0x28
0x2C
0x30
0x34
0x36
0x38

Tabela 11: Alguns campos do superbloco do EXT4

Nome
s_inodes_count
s_blocks_count_lo
s_blocks_per_group
s_inodes_per_group
s_mtime
s_wtime
s_mnt_count
s_max_mnt_count
s_magic

Descrio
Contador do total de inode
Contador do total de blocos
Blocos por grupo
Inodes por grupo
Tempo de montagem, em segundos desde o EPOCH
Tempo de escrita, em segundos desde o EPOCH
Quantidade de montagens antes de rodar o fsck
Quantidade mxima de montagens antes de rodar o fsck
Nmero mgico

O nmero de informaes armazenadas no superbloco do EXT4 tambm bem maior,


sendo que possvel visualizar alguns destes campos na Tabela 11, porm sem ultrapassar o tamanho
de 1024 bytes.

30

INLINE DATA
O EXT4 possui a capacidade de armazenar os dados dentro do mesmo bloco utilizado pelo
inode, contanto que o arquivo caiba dentro dele. Num inode de 256 bytes, o sistema de arquivos
consegue disponibilizar at 156 bytes para armazenamento de dados. Graas a esta capacidade, a
leitura se torna mais fcil, pois ao localizar o inode voc tem acesso automaticamente ao arquivo sem
a necessidade de executar posteriormente uma busca por seus blocos.
Existe uma alterao pendente no cdigo que permitir que seja possvel armazenar at
160 bytes num inode, j que atualmente o sistema de arquivos gerencia de maneira incorreta o espao
utilizado por eles.
POLTICA DE ALOCAO DE BLOCOS E INODES
A alocao dos blocos pelo EXT4 utiliza dos mtodos mballoc, delalloc, fallocate, block
group, e mais duas polticas de alocao. A primeira poltica que todos os blocos de um mesmo
arquivo sero salvos no mesmo grupo de blocos, se possvel. Dessa forma diminui o seek time em
disco j que toda a operao ocorrer na mesma regio do disco.
A segunda poltica implementada que todos os inodes e arquivos sero salvos no mesmo
grupo que seus diretrios. Esta poltica vlida para todos os grupos com exceo do grupo 0, que
responsvel pelo contedo do diretrio raiz. Caso uma pasta ou arquivo seja criada na raiz do sistema
de arquivos, o contedo ser salvo no grupo que estiver com menos uso.
2.5.2 PECULIARIDADES ENCONTRADAS
A seguir so descritos alguns problemas relatados pelos usurios ou at mesmos
encontrados nas especificaes do sistema.
PERDA DE DADOS
Muito reclamado pela comunidade, e at levantado em algumas discusses pelo Linus
Torvalds (2009), devido as novas polticas de gerenciamento de blocos do EXT4, a gravao de dados
pode levar algo em torno de 30 a 60 segundos. Um valor intolervel para muitos, visto que em alguns
casos 60 segundos pode ser uma perda significante de dados. Como soluo de contorno foi liberado
a opo de montagem nodelalloc, que permite desabilitar a alocao com atraso.
DOCUMENTAO OFICIAL PRECRIA
O EXT4 possui uma wiki11 que possui o material oficial sobre sua estrutura e design.
Porm boa parte do contedo encontrada de forma incompleta por falta de conhecimento de quem
estava escrevendo, e contedo desatualizado, j que algumas pginas no citam as funes
acrescentadas no cdigo esse ano.
SISTEMA DE ARQUIVOS 48bits
O EXT4 foi desenvolvido utilizando da unio de dois ponteiros para que seja possvel
gerenciar blocos acima de 32bits, porm mesmo com todo esse poder de armazenamento a comunidade
11

Wiki: utilizado para identificar qualquer coleo de documentos;

31

de desenvolvedores informa que esse valor terico e no d para saber qual seria o comportamento
do sistema de arquivos com arquivos realmente largos.
2.6 NEW TECHNOLOGY FILE SYSTEM (NTFS)
O NTFS um sistema de arquivos desenvolvido pela Microsoft (TECHNET, 2003) como
substituto do FAT16. Surgiu primeiramente como parte da famlia de sistemas operacionais Windows
NT, e desde ento o sistema de arquivos principal de todas as verses do Windows. um programa
de cdigo fechado que funciona na camada de kernel, recebendo as requisies dos processos,
executando, e ento repassando a mensagem de volta ao solicitante.
Entre as melhorias do NTFS, as que podemos destacar so:

Capacidade de armazenamento: Possui capacidade terica de receber 16TiB (com


clusters de 64kb) como maior arquivo, e gerncia parties de at 256TiB;
Segurana: O NTFS utiliza Listas de Controle de Acesso (ACL) como meio de
gerenciar qual usurio/processo tem acesso a determinado arquivo e quais so suas
respectivas permisses;
Nomes de arquivos logos: suporte a at 256 caracteres, isso excluindo as extenses;
Gerenciamento de arquivos com MFT: a localizao de arquivos, como tambm o
uso de clusters feito atravs de uma Tabela Mestre de Arquivos (MFT), que por sua
vez uma evoluo da FAT;
2.6.1 ESTRUTURA DE DADOS DO NTFS

Diferente do MINIX FS ou do EXT4, o NTFS divide seu disco em 4 reas: o Boot Sector,
a Tabela Mestre de Arquivos, os dados do disco, e uma cpia da Tabela Mestre de Arquivos.
Figura 18: Composio de um disco com o NTFS

Setor de
boot

NEW TECHNOLOGY FILE SYSTEM


Tabela Mestre
Backup da Tabela
Dados
de Arquivos
Mestre de Arquivos

CLUSTER
Cluster a menor unidade dentro da partio do NTFS, e funciona da mesma maneira que
um bloco. O NTFS possui capacidade de gerenciar em uma nica partio 2 cluster menos 1, e o
valor default de alocao de clusters varia de acordo com o tamanho da partio, conforme pode ser
visto na Tabela 12.
Tabela 12: Valores padro do tamanho do cluster do NTFS
Tamanho do Volume
Tamanho do Cluster do NTFS
7 MB 512 MB
512 bytes
513 MB 1,024 MB
1 KB
1,025 MB 2 GB
2 KB
2 GB 2 TB
4 KB

32

BOOT SECTOR
O NTFS armazena todos os dados relacionados a partio no setor de boot, ao contrrio
dos demais sistemas de arquivos. Essa partio possui o tamanho de at 16 setores (8KB) e consiste
dos seguintes elementos:

Uma instruo de jump para CPU baseada na arquitetura x86;


O identificador original de fabricante do equipamento (OEM ID);
O Bloco de Parmetros da BIOS;
Extenses do BPB;
O cdigo executvel que inicia o sistema operacional;

Ao final do setor de boot da partio pode ser localizado a assinatura do sistema de


arquivos, que 0x55AA. Na Tabela 13 possvel conferir alguns dos campos encontrados dentro do
bloco de parmetros. O campo 0x30 (Nmero do Cluster do MFT) utilizado para definir a localizao
do MFT, dessa forma permitindo que seja alocado para outra regio, caso a atual possua algum setor
defeituoso.
Byte Offset
0x0B
0x0D
0x0E
0x15
0x28
0x30
0x44

Tabela 13: Bloco de parmetros da BIOS


Nome do Campo
Descrio
Bytes por Setor
Tamanho de um setor do disco.
Setor por Cluster
Nmero de setores em um cluster.
Por padro o valor sempre deve ser 0 para designar a
Setores reservados
regio aonde se encontra o setor de boot.
Informa qual o tipo de mdia que armazena essa partio.
Descritor de mdia
F8 significa que se trata de um Hard Disk, enquanto F0
significa Floppy Disk .
Total de Setores
Nmero total de setores no disco
Nmero do Cluster do
Informa a localizao do MFT em disco.
MFT
Clusters para buffer de Informa o tamanho de cada buffer de index, na qual so
index
utilizados para alocar espao para diretrios.

MASTER FILE TABLE (MFT)


A Tabela Mestre de Arquivos (MFT) foi criada como uma evoluo da Tabela de Alocao
de Dados do FAT16. Ela possui o tamanho equivalente a 12,5% do tamanho total do disco, porm
pode ser ajustado para as seguintes configuraes:

Configurao 1 ou Default: Reserva 12,5% do disco para a tabela;


Configurao 2: Reserva 25% do disco para a tabela;
Configurao 3: Reserva 37,5% do disco para a tabela;
Configurao 4: Reserva 50% do disco para a tabela;

33

Vale ressaltar que essa configurao feita de forma automtica pelo NTFS, sendo que ele
se auto reconfigurar assim que notar que a tabela atingiu seu tamanho mximo. Nesse caso possvel
que a tabela acabe se fragmentando, j que as demais partes sero alocadas em regies diferentes do
disco de acordo com a disponibilidade. Tambm possvel configurar durante a formatao o tamanho
reservado para a MFT, dessa forma possvel evitar a fragmentao da tabela, porm voc perde
espao em disco para os registros.
A MFT reserva os primeiros 16 registros para seus prprios metadados, sendo eles
distribudos conforme a Tabela 14. Cada registro dentro da MFT possui o tamanho de 1KB e
armazenam alguns dados bsicos sobre o arquivo, como o nome dele. Dentro de um registro da MFT,
900 bytes so reservados para:

Registros Residentes: Quando um arquivo possui um tamanho menor que 900 bytes
ento ele salvo dentro do registro da MFT, dessa forma diminuindo o tempo que
seria perdido pesquisando pelo arquivo dentro do disco;
Atributos Residentes: Quando os atributos do arquivo possuem tamanho menor do
que 900 bytes eles so armazenados dentro da entrada do MFT;

Arquivo do Sistema
Master file table

Master file table mirror


Log file
Volume

Attribute Definitions

Root file name index


Cluster bitmap
Boot sector

Bad cluster file


Security file
Upcase table
NTFS extension file

Tabela 14: Entradas Reservadas para o MFT


Nome do Arquivo
Objetivo
$Mft
Cabealho do MFT
Cpia do arquivo $Mft para caso do primeiro
$MftMirr
ser danificado
Contm informaes sobre as alteraes
$LogFile
pendentes, para no caso de ocorrer uma parada
no sistema operacional
$Volume
Contm informaes sobre o volume
Lista de nomes de atributos, nmeros, e
$AttrDef
descrio
.
A pasta root (C:\)
Informa quais os clusters livres e quais esto
$Bitmap
em uso pelo volume
$Boot
Armazena informaes sobre o bloco de boot
Contm uma lista de todos os clusters
$BadClus
danificados no volume
Descritores de segurana para todos os
$Secure
arquivos em disco
Converte letras minsculas para serem
$Upcase
compatveis com os caracteres maisculo
Usado para extenses do NTFS, como quotas,
$Extend
identificadores de objetos, e pontos de repasse.

Diferente dos sistemas de arquivos como o EXT4 ou o MINIX FS, o NTFS pode possuir
uma lista de atributos que ultrapassa 900 bytes. Nesses casos um ou mais clusters podem ser reservados
para armazenar os atributos. Na Tabela 15 possvel ver uma lista de alguns desses atributos que a
MFT armazena.

34

TABELA DE DESCRITORES DE ARQUIVOS


O NTFS possui uma tabela de descritores de arquivos, porm com algumas diferenas: no
so 3 tabelas, e sim 1 s que mantida pelo prprio sistema de arquivos. Cada arquivo possui sua
prpria tabela de descritores, formada por dois tipos de descritores: os descritores de dados sem nome,
e os descritores de dados com nome. A nica diferena entre ambos que os sem nome so utilizados
para funes internas do sistema operacional, enquanto os descritores com nomes so disponibilizados
para os processos controlarem aonde esto acessando o arquivo.
Byte Offset
0x0B
0x0D
0x0E
0x15
0x28
0x30
0x44

Tabela 15: Atributos do MFT


Nome do Campo
Descrio
Bytes por Setor
Tamanho de um setor do disco.
Setor por Cluster
Nmero de setores em um cluster.
Por padro o valor sempre deve ser 0 para
Setores reservados
designar a regio aonde se encontra o setor de
boot.
Informa qual o tipo de mdia que armazena essa
Descritor de mdia
partio. F8 significa que se trata de um Hard
Disk, enquanto F0 significa Floppy Disk12 .
Total de Setores
Nmero total de setores no disco
Nmero do Cluster do MFT
Informa a localizao do MFT em disco.
Informa o tamanho de cada buffer de index, na
Clusters para buffer de index
qual so utilizados para alocar espao para
diretrios.
2.6.2 PECULIARIDADES ENCONTRADAS

A seguir so descritos alguns problemas relatados pelos usurios ou at mesmos


encontrados nas especificaes do sistema.
SISTEMA DE ARQUIVOS OBSOLETO
O NTFS ainda o sistema de arquivos para linha base da Microsoft a quase 20 anos, sendo
sua ltima grande atualizao foi no lanamento do NTFS 5 (Windows 2000). A Microsoft a anos
tenta desenvolver um sistema de arquivos superior a ele, porm o projeto sempre cancelado.
Atualmente existe um esforo para desenvolver o ReFS (Resilient File System) para que seja lanado
na prxima verso do Windows Server, com o intuito de solucionar diversos problemas relatados pelos
usurios.
SEM TOLERNCIA A FALHAS
O NTFS possui modelos para se recuperar aps falhas, como o Journaling, porm no
um sistema de arquivos que consegue contornar falhas. Tambm existem reclamaes dos usurios
referente a perda de dados da verso do NTFS do Windows 10.
12

O NTFS no possui suporte a disquetes, sendo esse campo meramente um resduo do FAT16. (TECHNET, 2003)

35

TABELA MESTRE DE ARQUIVOS NA MEMRIA


Outro ponto negativo, esse herdado do FAT16, que o NTFS precisa que toda sua tabela
de arquivo esteja em memria. Para as unidades de armazenamento atuais, que podem chegar at 1 TB
ou mais, pode ser um problema caso os arquivos venham a ser fragmentados ou sejam criados muitos
arquivos pequenos.

36

3. FERRAMENTAS DE TESTES
Neste captulo sero descritas as ferramentas que foram utilizadas durante os testes de
carga e comportamento dos sistemas de arquivos.
3.1 MINIX 3
O MINIX um sistema operacional de cdigo aberto baseado na arquitetura UNIX,
desenvolvido por Andrew Stuart Tanenbaum (TANENBAUM & WOODHULL, Sistemas
Operacionais: Projeto e Implementao, 2008) e mantido pela comunidade. Iniciou como uma
ferramenta educacional para seu livro Sistemas Operacionais Projeto e Implementao, porm
desde o lanamento a terceira verso do sistema, em 2005, o desenvolvimento tem sido focado para
dar suporte a aplicaes baseadas em processadores ARM. Mesmo no sendo mais seu foco, o MINIX
continua sendo uma excelente ferramenta para estudos.
3.2 UBUNTU SERVER
Ubuntu Server uma ramificao da distribuio Ubuntu, mantido pela Canonical, voltado
para servidores. Em sua 15 verso (Vivid Vervet), o Ubuntu possui como diferencial o fato dos pacotes
estarem sempre na verso mais recente, diferente das demais distribuies no mesmo ramo que lanam
somente atualizaes de correo. O Ubuntu tambm conhecido por possuir a maior quantidade de
pacotes compatveis com o sistema operacional.
3.3 MICROSOFT WINDOWS 10 PRO
O Microsoft Windows um sistema operacional pago de cdigo fechado, desenvolvido
pela Microsoft, com foco em usurios de desktops ou notebooks. Lanado em 2015, o Windows 10
veio com uma srie de novas funcionalidades e correes visuais, comparado ao seu antecessor, o
Windows 8.1. Entre elas o suporte ao Cortana e a volta do menu Iniciar. Apesar de no possuir nenhuma
atualizao ao seu sistema de arquivos, o Windows 10 ainda a melhor maneira de executar os testes.
3.4 DATASET DEFINITION DD
O dd um comando de sistemas operacionais baseados no UNIX que permite voc copiar
arquivos, informando origem/destino conforme a Figura 21. O diferencial do dd para outros comandos
do gnero (como o cp) que com o dd voc pode copiar qualquer coisa, como uma unidade de disco
inteira, alm de ser possvel tambm gerar arquivos com contedo randmico.
Os parmetros aceitos pelo dd que foram utilizados nos testes so:

if: Informa o arquivo de origem que pretende copiar;


of: Informa o arquivo de sada que receber o contedo;
bs: Informa o tamanho dos blocos alocados dentro do arquivo;
count: Informa quantas vezes a operao ser repetida;
conv: Permite passar um parmetro de como o dd deve ser executado. Nos testes ser
utilizado o parmetro fdatasync, que desabilita a alocao com atraso;

37

Figura 19: Exemplo do dd aps a execuo

Foi escolhido o dd para executar os testes de desempenho devido a sua simplicidade e


compatibilidade com os 3 sistemas operacionais (MINIX, Linux e Windows).
3.5 VMWARE WORKSTATION
O VMware Workstation virtualizador pago desenvolvido pela VMware Inc., com o intuito
de servir como uma forma de desenvolvedores testarem suas aplicaes em um ambiente isolado, antes
de colocarem eles em produo. Diferente de outros no mesmo ramo, como o VirtualBox, da Oracle
Corporation, ou o descontinuado Virtual PC, da Microsoft, o VMware Workstation j uma ferramenta
com 15 anos de desenvolvimento, com um grande histrico de estabilidade e desempenho.
O VMware possui compatibilidade com o MINIX, Ubuntu Server, e Windows 10
virtualizados. Abaixo segue as configuraes de hardware das mquinas virtuais:

1 vCPU;
1 GB de Memria RAM;
Hard Disk de 60 GB (Necessrio principalmente para o Windows);

38

4. REALIZAES DE TESTES
Neste captulo sero discutidos sobre os testes de carga realizados atravs do dd e anlise
comportamental dos discos.
4.1 TESTE DE CARGA
A execuo do dd nas mquinas virtuais foi realizado de duas formas: a primeira pegando
o tempo de criao de um nico arquivo, e depois o tempo de criao de mltiplos arquivos. Voc pode
conferir os tempos de criao nos grficos abaixo. Executar os testes com o dd se provou desafiador
devido aos relatrios de tempo sarem de forma inconsistente. Isso ocorre em ambientes virtuais com
facilidade devido a mquina virtual competir a escrita com outras mquinas virtuais e tambm com o
prprio sistema operacional hospedeiro (no caso o Windows 10).
4.1.1 CRIAO DE UM NICO ARQUIVO
Figura 20: Criao de um nico arquivo via dd
180
160

Tempo (em segundos)

140
120
100

Minix FS V3

80

EXT4

60

NTFS

40
20
0

1 MB

10 MB

100 MB
500 MB
Tamanho do Arquivo

1 GB

2 GB

Durante a primeira etapa dos testes, o MINIX FS se saiu relativamente bem at comear a
utilizar os blocos de indireo dupla, quando o tempo de criao passou a crescer conforme o arquivo
tambm crescia. Isso ocorre porque o MINIX ainda utiliza a antiga funo de alocao de blocos
balloc, aonde alocado bloco a bloco no disco. J o NTFS e o EXT4 tiveram desempenhos
semelhantes, sendo o NTFS mais rpido por questo de segundos. Isso ocorre pois ambos trabalham
com alocao de Multiblocos, alm de que as mudanas na MFT e na Inode de cada um com o objetivo
de melhorar o desempenho se provaram efetivas.
4.1.2 CRIAO DE MLTIPLOS ARQUIVOS (1 MB)
Ao executar o loop de criao de arquivos, o dd teve o melhor desempenho do EXT4,

39

levando at 128 segundos para criar 16000 arquivos em disco, porm sofreu instabilidade durante o
teste de 2000 arquivos: levou 2 segundos a mais do que durante a teste de 4000 arquivos. O MINIX,
por outro lado teve dificuldade em armazenamento de dados, levando 367 segundos para gravar
exatamente a mesma quantidade, e ainda apresentou um segundo problema: no conseguiu eliminar
esses arquivos posteriormente. Na tentativa foi alegado falta de memria, mesmo que outras
ferramentas (free ou o top) informassem o contrrio.
O NTFS no teve problemas para excluir os arquivos, tambm no sofreu de instabilidade,
porm o tempo de criao foi o maior dos testes: 534 segundos para concluir a atividade.
Figura 21: Criao de multiplos arquivos via dd (1 MB)
600

Tempo (em segundos)

500
400
300

Minix FS V3

200

NTFS

EXT4

100
0

1000

2000

4000
8000
Quantidade de Arquivos

12000

16000

4.1.3 CRIAO DE MLTIPLOS ARQUIVOS (10 MB)


Durante os testes de arquivos de 10 MB, a quantidade de arquivos gerados foi reajustada
para que o loop possa continuar gerando 16 GB de dados. O intuito foi para que os resultados tambm
mostrassem qual seria o comportamento do sistema de arquivos ao lidar com pequenos arquivos e
grandes arquivos.
Sem nenhuma surpresa, os piores resultados vieram do MINIX mais uma vez, porm dessa
vez o tempo de criao caiu para 336 segundos, como pode ser visto na Figura 24. No teve problemas
para excluir os arquivos aps a criao. O EXT4 manteve seu desempenho, porm ainda apresentando
instabilidade na criao dos arquivos, possuindo tempo de criao semelhante entre 800 arquivos e
1200 arquivos. J o NTFS possui um tempo de criao melhor com arquivos de 10 MB do que com
arquivos de 1MB. Com a mesma quantidade de informaes sendo armazenadas, 16 GB de arquivos
de 10 MB levaram 82 segundos para serem escritas em disco.

40

Figura 22:Criao de multiplos arquivos via dd (10 MB)


400

Tempo (em segundos)

350
300
250
Minix FS V3

200

EXT4

150

NTFS

100
50
0

100

200

400
800
Quantidade de Arquivos

1200

1600

4.1.4 CRIAO DE MLTIPLOS ARQUIVOS (100 MB)


Figura 23: Criao de multiplos arquivos via dd (100 MB)
350

Tempo (em segundos)

300
250
200

Minix FS V3

150

EXT4
NTFS

100
50
0

10

20

40
80
Quantidade de Arquivos

120

160

Novamente perceptvel um aumento de desempenho conforme o tamanho dos arquivos


tambm aumenta, porm, os tempos do MINIX continuam inferiores aos do EXT4 e do NTFS.
Novamente o EXT4 sofre de intermitncia do tempo de criao, possuindo um pssimo tempo ao criar
20 arquivos de 100 MB, porm o resultado se sai melhor ao criar 40 arquivos de 100 MB. O NTFS
novamente teve o melhor desempenho, levando 38 segundos para criar 160 arquivos de 100 MB.

41

interessante notar que o excesso de tempo que o NTFS levava para criar os arquivos diminui conforme
se aumenta o tamanho deles e diminui a quantidade.
4.1.5 CRIAO DE MLTIPLOS ARQUIVOS (1 GB)
Figura 24: Criao de multiplos arquivos via dd (1GB)
350

Tempo (em segundos)

300
250
200

Minix FS V3

150

EXT4
NTFS

100
50
0

4
8
Quantidade de Arquivos

12

16

Criar arquivos grandes (+ 1 GB) demonstra que por mais que o MINIX possua capacidade
para tratar eles, no foi feito com esse propsito. Mesmo com arquivos pequenos ainda existia uma
perda de desempenho comparado ao NTFS e o EXT4, e o aumento do tamanho no mudou muita
coisa. O EXT4 e o NTFS possuram tempo de armazenamentos semelhantes, porm no fim o NTFS
acabou tendo novamente o melhor desempenho, levando 29 segundos para gravar 16 arquivos de 1
GB em disco, enquanto o EXT4 levou 84 segundos.
4.1.6 CONCLUSES
Conforme pode ser visto, mesmo a anos sendo desenvolvido, o MINIX FS possui o pior
desempenho quando se trata da velocidade de armazenar dados, e suas tecnologias tambm podem ser
consideradas obsoletas. J o EXT4 possui um desempenho aceitvel, porm possui uma instabilidade
de desempenho causado pelo prprio sistema de arquivos que monitora o melhor momento para
armazenar, dessa forma no se sobrecarregando de tarefas. O NTFS, por outro lado, conseguiu manter
os tempos de maneira estvel, porm tem um pssimo desempenho quando se trata de arquivos
pequenos.
4.2 USO DO SISTEMA DE ARQUIVOS
Nesse tpico sero discutidos sobre os sistemas de arquivos em produo, como o
comportamento deles em ambiente de produo, entre outros.

42

4.2.1 MINIX FS V3
O MINIX FS no to diferente quanto outros sistemas de arquivos UNIX-like, com o
EXTFS, XFS, ou o JFS. Ele possui suporte a alguns metadados de arquivos, no ocupa tanto espao
em disco, e possui uma estrutura simples e organizada. Para quem busca compreender como funciona
um sistema de arquivos, ele perfeito para esse tipo de compreenso, porm para uso no to bom
assim. As limitaes de 2GB para o tamanho mximo de arquivos hoje em dia um bom empecilho,
sendo que a grande maioria dos sistemas de arquivos 32 bits j possuem suporte ao LFS.
Outro ponto negativo a chance de perda de dados no sistema de arquivos ser grande:
mesmo avisando que o arquivo j est salvo em disco, o MINIX ainda no havia iniciado a rotina de
sync. Durante os testes foi comprovado que existe a possibilidade de o arquivo desaparecer em caso
de falta de energia. Isso ocorre porque o MINIX grava por ltimo os metadados em disco, ao contrrio
dos demais que armazenam primeiro.
A incompatibilidade do sistema de arquivos com suas verses anteriores tambm complica
caso deseje migrar os dados. Sua melhor chance criar uma partio EXT2 e ento armazenar os dados
nessa partio. Esse problema j foi solucionado na verso do LINUX do MINIX FS, porm a verso
do LINUX no sabe gerenciar blocos maiores do que 64KB. Na melhor das possibilidades, o MINIX
perfeito para usar em dispositivos pequenos, como disquetes, ou para estudos. Porm para o uso do
dia a dia existem melhores.
4.2.2 FOURTH EXTENDED FILE SYSTEM (EXT4)
O EXT4 foi desenvolvido para ser a verso mais robusta do EXT3, que havia sido
apresentado como uma soluo para os problemas do EXT2, porm no fim acabou criando outros, em
principal a perda de desempenho causada pelo Journaling. A ideia de substituir o modelo de alocao
de blocos indiretos por extenses funcionou perfeitamente, sendo que agora possui suporte a arquivos
grandes, muito mais do que seu antecessor suporta.
Outro ponto a incluso de novas polticas de alocao de dados, como o delalloc. Isso
mitigou muito a fragmentao de dados, j que agora o sistema de arquivos espera ao mximo pelo
melhor momento antes de alocar os arquivos em disco. Outro diferencial que agora possvel
formatar uma partio sem o Journaling, o que aumenta o espao e o desempenho, em troca da
resilincia.
Por outro lado, o EXT4 tem sofrido por causa de seus problemas, principalmente com a
alocao com atraso. Existem casos em que a alocao com atraso no respeita o commit_timeout,
ocasionando em perda de dados, e outras em que o usurio gostaria de usufruir dos recursos do EXT4,
porm no quer arriscar a perda de 60 segundos de dados, motivo pelo qual posteriormente foi criado
a opo de montagem nodelalloc.
Outros problemas vistos so dentro da prpria comunidade, aonde existe uma briga entre
aqueles que apoiam os recursos do EXT4, e aqueles que so contra eles. Isso tem afetado muito a
imagem do sistema de arquivos, ao ponto de algumas empresas cogitarem a substituio dele por outro,
como por exemplo o Btrfs.
4.2.3 NEW TECHNOLOGY FILE SYSTEM (NTFS)
O NTFS pode no aparentar ser to velho, porm dos 3 o sistema de arquivos mais antigo.
Foi desenvolvido no ano de 1993, e de l para c no sofreu muitas alteraes para incluso de novas
funes, porm possui a maior estabilidade entre os trs. Sua ltima grande mudana foi o lanamento
do NTFS 5, que foi lanado junto com o Windows 2000. O foco dele servidores, ento toda sua

43

estrutura foi feita para atender essa demanda desde aquela poca, porm como desktops tambm
precisavam abandonar o FAT16, ento o mesmo sistema de arquivos utilizado para mquinas clientes.
O sistema de arquivos possui abordagens interessantes, como a tabela de descritores de
arquivos ser simplificada em 1 nica por arquivo, porm to simplista quanto o MINIX FS. Por ser
um sistema de arquivos antigo, era de se esperar que j tivesse sido substitudo por outro, porm a
Microsoft no obteve sucesso at o momento em desenvolver um.
O maior problema com o NTFS a MFT, um legado dos sistemas de arquivos FAT. Assim
como seu antecessor, a MFT obrigada a ficar inteira cacheada em memria, o que pode ser um
problema dependendo do tamanho total da tabela e o quanto de memria voc possui. Outro ponto
negativo a falta de documentao do NTFS, sendo que a maioria encontrada bem rasa, com exceo
de alguns feitos por fs que so bem detalhados, ou uma documentao ou outra da Microsoft. E
mesmo esses documentos esto desatualizados, com por exemplo a TechNet (2003) que a ltima
atualizao foi em 2003.
O ltimo ponto no chega a ser negativo, e sim curioso. O NTFS possui o bootloader j
instalado na partio, mesmo que ela no seja inicializvel. Na documentao informado que a regio
livre caso no seja inicializvel, porm ao formatar um disco com o NTFS foi possvel notar o
bootloader nos primeiros 1024 bytes do disco.

44

5. CONSIDERAES FINAIS
O objetivo final desse trabalho foi realizar um estudo em trs sistemas de arquivos
diferentes com o intuito de compreender seu funcionamento. Para conseguir atingir esse objetivo foi
necessrio um estudo inicial de como os sistemas de arquivos funcionam, levantando toda a parte
terica das funcionalidades sem focar em um nico sistema de arquivos. Com essas informaes foi
possvel ento compreender como cada um dos sistemas de arquivos apresentados se comportam.
Diversos problemas foram encontrados ao longo do tempo, como a falta de material
didtico para alguns dos sistemas de arquivos, ou ferramentas que fossem compatveis em diferentes
sistemas operacionais. Outro ponto que se mostrou uma dificuldade foi encontrar uma maneira que os
testes pudessem ocorrer de forma que uma fonte externa no interferisse nela. Mquinas virtuais
acabaram se mostrando a melhor maneira de executar eles, apesar do desempenho estar merc do
computador cliente que estivesse executando. At mesmo os testes de carga dos sistemas de arquivos
se mostraram afetados em alguns momentos quando o teste foi realizado em ambiente de nuvem.
Considera-se que o objetivo foi atingido, porm ainda existe campo a ser explorado dentro
desse tema. Durante o projeto foi levantado diversas ideias do que mais poderia ser explorado, porm
pela falta de tempo tiveram que ficar de fora.

45

6. LISTA DE ABREVIAES
NTFS New Technology File System
EXT4 Fourth Extended File System
FS File System
POSIX Portable Operating System Interface
IEEE - Institute of Electrical and Electronics Engineers
EOF End of File
MBR Master Boot Record
GPT GUID Partition Table
GUID Globally Unique Identifier
UEFI Unified Extensible Firmware Interface
BIOS Basic Input/Output System
MFT Master File Table

46

7. REFERNCIAS
BOVETI, D. P., & CESATI, M. (2002). Understanding Linux Kernel. O'Reilly.
BRUDERHOFER, N. (2006). EdisonPhonograph.jpg. Fonte:
https://de.wikipedia.org/wiki/File:Phonograph.jpg
BUTTERWORTH, N. (2012). All about EOF. Acesso em 5 de dez. de 2015, disponvel em
https://latedev.wordpress.com/2012/12/04/all-about-eof
CALLEJA, D. (2008). EXT4. Acesso em 13 de nov. de 2015, disponvel em
http://kernelnewbies.org/Ext4
CARD, R., TS'O, T., & TWEEDIE, S. (2015). ext2-inode.gif. Fonte:
http://e2fsprogs.sourceforge.net/ext2-inode.gif
DJWONG. (2014). EXT4 Disk Layout. Acesso em 13 de nov. de 2015, disponvel em
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
GITHUB. (2015). About GitHub. Acesso em 18 de ago. de 2015, disponvel em
https://github.com/about
HARRIS, M. (2010). What is a B+ Tree? Acesso em 27 de set. de 2015, disponvel em
https://www.quora.com/What-is-a-B+-Tree
HSIUNG, S. (2009). ext4-builds-an-extent-tree-for-larger-files.png. Fonte:
http://www.datarecoverytools.co.uk/wp-content/uploads/2009/11/ext4-builds-an-extent-treefor-larger-files.png
IDEMA. (2011). Advanced Format (AF) Technology. Acesso em 8 de nov. de 2015, disponvel em
http://www.idema.org/?page_id=98
IEEE , C. (2008). Standard for Information Technology Portable Operating System Interface
(POSIX(R). Acesso em 16 de ago. de 2015, disponvel em
https://standards.ieee.org/findstds/standard/1003.1-2008.html
JONES, M. T. (2008). Anatomia dos Sistemas de Arquivos de journaling do Linux. Acesso em 20 de
ago. de 2015, disponvel em http://www.ibm.com/developerworks/br/library/l-journalingfilesystems/
JUNIOR, P. G. (2015). Trabalhando com o sistema de arquivos NTFS - Parte I. Acesso em 30 de
set. de 2015, disponvel em https://technet.microsoft.com/pt-br/library/cc716477.aspx
MAN. (2001). Linux Programmer's Manual.
MICROSOFT. (2015). Comparando sistemas de arquivos NTFS e FAT. Acesso em 15 de ago. de
2015, disponvel em http://windows.microsoft.com/pt-br/windows-vista/comparing-ntfs-andfat-file-systems
MISTWIZ. (2008). Disk-structure2.svg. Fonte:
https://upload.wikimedia.org/wikipedia/commons/a/ae/Disk-structure2.svg
MORIMOTO, C. E. (2007). Disco Rgido. Acesso em 15 de out. de 2015, disponvel em
http://www.hardware.com.br/termos/disco-rigido
RODRIGUES, G. (2013). Modificadores de Variveis. Acesso em 18 de out. de 2015, disponvel em
http://personalizandoc.blogspot.com.br/2013/02/modificadores-de-variaveis.html
STROSS, R. (2010). The Incredible Talking Machine. Acesso em 30 de set. de 2015, disponvel em
http://content.time.com/time/specials/packages/article/0,28804,1999143_1999210_1999211,0
0.html

47

TANENBAUM, A. S. (2010). MINIX 3: status report and current research. Acesso em 30 de out. de
2015, disponvel em http://www.minix3.org/docs/login-2010.pdf
TANENBAUM, A. S., & WOODHULL, A. S. (2008). Sistemas Operacionais: Projeto e
Implementao. Bookman.
TECHNET. (2003). How NTFS Works. Acesso em 30 de set. de 2015, disponvel em
https://technet.microsoft.com/pt-br/library/cc781134%28v=ws.10%29.aspx
TECHNET. (2015). Master Boot Record. Acesso em 17 de set de 2015, disponvel em
https://technet.microsoft.com/en-us/library/cc976786.aspx
WOLSKI, R. (2014). filetable.rich.jpg. Acesso em 5 de dez de 2015, disponvel em
http://www.cs.ucsb.edu/~rich/class/cs170/notes/FileSystem/filetable.rich.jpg