Sistemas de Arquivos

CENTRO UNIVERSITÁRIO FIEO

LUCAS COSTA BEYELE

SISTEMAS DE ARQUIVOS

OSASCO 2015

CENTRO UNIVERSITÁRIO FIEO

LUCAS COSTA BEYELE

SISTEMAS DE ARQUIVOS

Projeto Integrado de Graduação apresentado ao Curso de Ciência da Computação do Centro Universitário FIEO - UNIFIEO, como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação. Orientadora: Profa. Dra. Andreia C. G. Machion.

OSASCO 2015

AGRADECIMENTOS

Agradeço 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 correções e incentivos. Aos meus pais e irmão 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 formação o meu muito obrigado.

LISTA DE FIGURAS

Figura 1: Fonógrafo ........................................................................................................................ 10 Figura 2: Áreas de um disco ............................................................................................................ 11 Figura 3: Cabeçalho de um arquivo ................................................................................................. 12 Figura 4: Diretório aberto com o editor de texto Vim ...................................................................... 14 Figura 5: Um bloco de 4KB formado por 8 setores de 512 bytes ..................................................... 14 Figura 6: Eficiência do espaço em disco X Taxa de transferência .................................................... 15 Figura 7: Exemplo de alocação contígua: ........................................................................................ 17 Figura 8: Exemplo de alocação encadeada ...................................................................................... 18 Figura 9: Exemplo da Tabela de Alocação de Arquivos .................................................................. 18 Figura 10: Um inode com os blocos de indireção ............................................................................ 19 Figura 11: Relacionamento entre as tabelas de arquivos .................................................................. 21 Figura 12: Composição 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: Composição de um disco com o EXT4 ........................................................................... 27 Figura 17: Uma árvore de extensões ................................................................................................ 28 Figura 18: Composição de um disco com o NTFS ........................................................................... 31 Figura 19: Exemplo do dd após a execução ..................................................................................... 37 Figura 20: Criação de um único arquivo via dd ............................................................................... 38 Figura 21: Criação de multiplos arquivos via dd (1 MB) ................................................................. 39 Figura 22:Criação de multiplos arquivos via dd (10 MB) ................................................................ 40 Figura 23: Criação de multiplos arquivos via dd (100 MB) ............................................................. 40 Figura 24: Criação de multiplos arquivos via dd (1GB) ................................................................... 41

LISTA DE TABELAS

Tabela 1: Cronograma do trabalho .................................................................................................... 9 Tabela 2: Lista de extensões e assinaturas comuns .......................................................................... 13 Tabela 3: Setores do MBR .............................................................................................................. 16 Tabela 4: Layout básico de uma tabela GUID ................................................................................. 16 Tabela 5: Sistemas de arquivos e seus números mágicos ................................................................. 17 Tabela 6: Algumas mensagens do sistema de arquivos .................................................................... 22 Tabela 7: Conteúdo do cabeçalho das extensões .............................................................................. 28 Tabela 8: Conteúdo dos nós das extensões ...................................................................................... 28 Tabela 9: Conteúdo das folhas das extensões .................................................................................. 28 Tabela 10: Tabela de inodes reservadas ........................................................................................... 29 Tabela 11: Alguns campos do superbloco do EXT4 ........................................................................ 29 Tabela 12: Valores padrão do tamanho do cluster do NTFS ............................................................ 31 Tabela 13: Bloco de parâmetros da BIOS ........................................................................................ 32 Tabela 14: Entradas Reservadas para o MFT ................................................................................... 33 Tabela 15: Atributos do MFT .......................................................................................................... 34

SUMÁRIO

1. Introdução ..................................................................................................................................... 8

1.1 Objetivo Geral ......................................................................................................................... 8 1.2 Objetivos Específicos .............................................................................................................. 8 1.3 Justificativa ............................................................................................................................. 8 1.4 Metodologia ............................................................................................................................ 9

2. Fundamentação Teórica .............................................................................................................. 10 2.1 Dispositivo de Armazenamento ............................................................................................. 10 2.2 Disco Rígido ......................................................................................................................... 10 2.3 Sistemas de Arquivos ............................................................................................................ 11

2.3.1 Estrutura Básica .............................................................................................................. 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. Realizações de Testes .................................................................................................................. 38 4.1 Teste de Carga ....................................................................................................................... 38

4.1.1 Criação de um Único Arquivo ......................................................................................... 38 4.1.2 Criação de Múltiplos Arquivos (1 MB) ........................................................................... 38 4.1.3 Criação de Múltiplos Arquivos (10 MB) ......................................................................... 39 4.1.4 Criação de Múltiplos Arquivos (100 MB) ........................................................................ 40 4.1.5 Criação de Múltiplos Arquivos (1 GB) ............................................................................ 41 4.1.6 Conclusões ...................................................................................................................... 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. Considerações Finais ................................................................................................................... 44

6. Lista de Abreviações ................................................................................................................... 45 7. Referências ................................................................................................................................. 46

8 1. INTRODUÇÃO

A cada dia, quantidades enormes de informação são geradas, e cada vez mais tem-se a

necessidade de armazená-las e restaurá-las com velocidade e facilidade. Para isso são utilizados algoritmos e técnicas eficientes que permitam armazenar e recuperar informações, é aí que surge a necessidade dos Sistemas de Arquivos.

“Um sistema de arquivos é a estrutura usada pelo computador para organizar dados em um disco rígido”. (MICROSOFT, 2015)

O tempo foi passando e o volume de dados gerados e a capacidade dos dispositivos de armazenamento foi aumentando, forçando 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 situações 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 distribuído (CEPH, GlusterFS);

Este trabalho possui como objetivo apresentar três sistemas de arquivos e suas arquiteturas,

executar testes para análise de comportamento, e então apresentar as conclusões em relação ao que foi encontrado nesses experimentos.

1.1 OBJETIVO GERAL

Realizar um estudo sobre como os dados são gerenciados por três sistemas de arquivos

populares: MINIX V3 FS, Fourth Extended File System (EXT4) e o New Technology File System (NTFS), para compreensão do seu funcionamento.

1.2 OBJETIVOS ESPECÍFICOS

A fim de cumprir o objetivo geral deste estudo, tem-se os seguintes objetivos específicos:

Estudo do funcionamento básico de um sistema de arquivos, analisando suas

funcionalidades; Mapeamento da estrutura do MINIX FS, EXT4 e NTFS para análise; Testes para análise de comportamento dos sistemas de arquivos, principalmente

quando colocados sob pressão; Desenvolvimento da documentação, apresentando conclusões obtidas a partir dos

estudos;

1.3 JUSTIFICATIVA

O MINIX FS é um sistema de arquivos gratuito e com código fonte aberto desenvolvido por Andrew Stuart Tanenbaum como parte do sistema operacional MINIX (TANENBAUM & WOODHULL, Sistemas Operacionais: Projeto e Implementação, 2008), sendo que se encontra atualmente em sua terceira versão. O EXT4 trata-se de um dos sistemas de arquivos mais utilizados

9 atualmente, que também é de código aberto e desenvolvido por uma enorme comunidade, sendo encontrado como default de diversas distribuições UNIX-like (CALLEJA, 2008). O NTFS é o mais recente sistema de arquivos da Microsoft, de código 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 características, os três 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 teórico: Será realizado um estudo aprofundado sobre o tema, empregando técnicas de engenharia reversa no sistema de arquivos (somente nos de código aberto) e pesquisa em materiais técnicos disponibilizados pelos desenvolvedores;

Execução de testes: Serão efetuados testes de carga a fim de analisar o desempenho do disco com determinado sistema de arquivo;

Conclusões: A última etapa será escrever a documentação incluindo os resultados obtidos durante os testes;

Tabela 1: Cronograma do trabalho

Tarefas Agosto Setembro Outubro Novembro Embasamento Teórico x x x

Execução de Testes x x x Conclusões x

10 2. FUNDAMENTAÇÃO TEÓRICA

Neste capítulo será tratado sobre dispositivos de armazenamento, em específico o disco

rígido, o que são sistemas de arquivos, detalhando suas arquiteturas técnicas e lógicas. Também são descritas as arquiteturas do MINIX FS (TANENBAUM & WOODHULL, 2008), NTFS (TECHNET, 2003), e o EXT4 (CALLEJA, 2008).

Figura 1: Fonógrafo

Fonte: (BRUDERHOFER, 2006)

2.1 DISPOSITIVO DE ARMAZENAMENTO

Dispositivo de armazenamento é um meio utilizado para armazenar informações 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 técnicas de armazenamento não são algo recente, sendo o fonógrafo, uma invenção de Thomas Edson, o primeiro meio de armazenamento mecânico que se tem registro. Para armazenar algum tipo de melodia, o fonógrafo utiliza uma espécie de cilindro para armazenamento, aonde uma agulha teria a tarefa de riscar as vibrações causadas pelo áudio em sulcos cobertos por uma folha de estanho (STROSS, 2010).

2.2 DISCO RÍGIDO

De acordo com Morimoto (2007), disco rígido é um sistema de armazenamento de alta

capacidade, que por não ser volátil, é destinado ao armazenamento de arquivos e programas. Internamente ele é formado por uma estrutura de discos magnéticos aonde serão armazenados os dados, e o cabeçote 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 inglês), e a busca dos dados é sempre realizada de forma sequencial: para ler um determinado setor, a agulha deverá viajar todos os n blocos que estão entre a posição 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 várias partes conforme a Figura 2, porém as mais relevantes ao

sistema de arquivos são: Setores: a menor unidade do disco rígido, possuía tamanho de até 512 bytes em

unidades antigas, porém atualmente, graças ao Advanced Format1, pode possuir o tamanho de 4096 bytes. Nem todos os componentes do computador se utilizarão 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 círculo concêntrico que começa no fim do disco e vai diminuindo de tamanho conforme se aproximam do centro;

Cilindro: os cilindros são conjuntos de trilhas que possuem a mesma numeração 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 rígido. Todos os livros, antes de serem colocados na estante são catalogados numa base de dados, que armazena informações como nomes dos livros, localização deles nas estantes, data de compra, histórico de pessoas que acessaram o livro, entre outros.

Um sistema de arquivos não é muito diferente: todos os arquivos criados numa máquina possuem suas informações salvas dentro de uma tabela (Tabela de Alocação de Dados ou uma Tabela de Inodes dependendo da arquitetura) que serão utilizadas posteriormente para recuperação do arquivo.

Conforme dito por Tanenbaum (TANENBAUM & WOODHULL, 2008), o armazenamento de informações deve respeitar as seguintes regras:

Deve ser possível armazenar um volume muito grande de informações; As informações devem sobreviver ao término do processo que as estão utilizando;

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

12 Vários processos devem ser capazes de acessar as informações concomitantemente;

2.3.1 ESTRUTURA BÁSICA

Neste tópico serão tratadas sobre as partes básicas da estrutura, como arquivos e seus formatos, diretórios e suas divisões. ARQUIVOS

Os arquivos são um mecanismo de abstração. Eles proporcionam uma maneira de armazenar informações no disco e de lê-las posteriormente. Isso deve ser feito de modo a esconder do usuário os detalhes sobre como e onde as informações são armazenadas e como os discos realmente funcionam (TANENBAUM & WOODHULL, 2008).

Figura 3: Cabeçalho de um arquivo

Para auxiliar nessa abstração de dados, o sistema de arquivos permite que um nome e uma

extensão sejam colocados no arquivo, assim o usuário poderá saber do que se trata o conteúdo do arquivo e também poderá ser lembrado que programa deve ser utilizado para ter acesso ao conteúdo. A quantidade de caracteres disponíveis para o nome varia de sistema de arquivos para outro, também quais caracteres são válidos como nome de arquivo. Já para a extensão são disponibilizados somente 3 caracteres com exceção do ponto (.). FORMATO DE ARQUIVOS

De forma genérica, o sistema de arquivos possui somente dois formatos para arquivos:

Arquivos de Texto: onde o conteúdo é escrito e lido no estado em que se encontra, sem possuir nenhum caractere especial com exceção do EOF (End of File 2);

Arquivos Binários: onde o conteúdo possui algum tipo de formatação especial que o impede de ser lido por outros processos que não sejam aquele que o gerou;

2 End of file: A constante EOF é utilizada como valor retornado por diversas funções para indicar que o final do arquivo chegou, ou também falhas sobre certas condições. 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

Tabela 2: Lista de extensões e assinaturas comuns Extensão Assinatura Significado

Db 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 Arquivo de banco do SQLite

Png 89 50 4E 47 0D 0A 1A 0A Arquivo de imagem PNG Xlsx 50 4B 03 04 14 00 06 00 Planilha eletrônica escrita no Microsoft Excel

2007 em diante Odt 50 4B 03 04 Arquivo de texto escrito no Libre Office Writer Tar 75 73 74 61 72 Arquivo tar empacotado

Para o usuário e o sistema de arquivos isso não ajuda muito, pois fica difícil identificar

qual foi o processo que o gerou ou do que se trata seu conteúdo. Para solucionar esse problema foram criados dois modelos: o primeiro onde a identificação do arquivo fica por conta de o sistema operacional reconhecer sua extensão, e a outra o reconhecimento é feito pelo sistema de arquivos utilizando uma “assinatura” no cabeçalho do arquivo. A Tabela 2 mostra alguns exemplos para extensões 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 diferença entre um modelo e outro é que, utilizando a assinatura, você garante que está abrindo o arquivo com a ferramenta correta. Neste caso a extensão se torna um lembrete para o usuário do que se trata aquele arquivo.

NOME DE ARQUIVOS

A atribuição 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 são:

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 disponíveis: Alguns sistemas de arquivos utilizam o padrão UTF-16 (FAT), enquanto outros não aceitam o caractere ponto (EXT);

Case-sensitive: Algo como “sensível ao tamanho das letras”, um sistema case-sensitive identifica que um arquivo chamado OLAMUNDO.txt não possui o mesmo nome que olamundo.txt (NTFS);

Informações 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 característica que o destino não sabe tratar, ou o destino pode tentar tratar de tal peculiaridade apresentando algumas possibilidades de correção para o usuário. DIRETÓRIOS

Diretórios, ficheiros, ou pastas, são três nomes diferentes para a mesma função: criar uma

camada de abstração que auxilie um usuário ou processo a organizar seus dados de uma forma que

14 possam ser facilmente localizados. Isso é necessário pois a maneira do sistema de arquivos localizar dados dentro de um disco é por meio de seu endereço armazenado dentro de uma tabela.

A parte a questão de organização de arquivos, diretórios também são uma forma de divisão das tabelas de localização de dados para alguns sistemas de arquivos. Em vez de percorrer uma tabela gigantesca, fica mais rápido varrer tabelas menores, sendo que essas tabelas menores possuiriam como identificador um nome (no caso o nome do diretório) e duas entradas obrigatórias: a do diretório acima e sua própria entrada.

Figura 4: Diretório aberto com o editor de texto Vim

Em alguns casos o diretório é somente outro arquivo, um de texto no caso, sendo possível

ler seu conteúdo 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 são outros diretórios, e os brancos são arquivos de texto ou outro conteúdo qualquer que seja visível ao usuário.

2.3.2 ESTRUTURA INTERNA

Aqui veremos a estrutura técnica de um sistema de arquivos, como o esquema de alocação de dados, bloco de boot, e superbloco. BLOCO OU CLUSTER

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

512 bytes 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes BLOCO DE 4K

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

unidade do sistema de arquivos: trata-se de uma região 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 3 Em alguns sistemas operacionais, colocar o ponto no início do nome do arquivo significa que ele é oculto, como por exemplo o UNIX. Outros, como o Windows, tratam a ocultação do arquivo como um atributo;

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, além de um valor que atende quase todas as necessidades).

Um bloco sempre será exclusivo ao dado que está armazenado nele, mesmo que ainda possua espaço para armazenar mais coisas dentro dele. Isso ocorre porque o sistema de arquivos controla um bloco inteiro, e não somente parte dele. Sendo assim problemas de controle e até permissão seriam frequentes, e para solucioná-los seria necessário um trabalho desnecessário do processador em troca de um pouco mais de espaço.

O tamanho do bloco interfere no seek time 4 e na quantidade de arquivos que podem ser armazenados. Na Figura 6 é possível ver que quanto maior for o bloco menor será o seek time, e também menor será a quantidade de arquivos que poderão ser armazenados. Caso os blocos sejam pequenos, o seek time será maior pois o arquivo possuirá mais fragmentos, porém será possível armazenar mais arquivos em disco.

Figura 6: Eficiência do espaço em disco X Taxa de transferência

BLOCO DE BOOT

Bloco de boot é a primeira área do disco, que possui tamanho máximo de 1024 bytes (2 setores), e que é responsável por inicializar o conteúdo do disco durante o arranque do computador, por exemplo o Sistema Operacional. Em seu conteúdo pode ser encontrado um número mágico informando se a partição é inicializável ou não, e o código que será responsável pela inicialização do sistema (um bootloader).

O acionamento do bloco de boot pode ser feito de duas maneiras: através do Registro Mestre de Inicialização (MBR) ou através da Tabela de Partição GUID (GPT). 4 Seek time: indica o tempo que a cabeça de leitura demora para ir de uma trilha à outra do disco, ou seja, indica a performance da agulha usada no HD (MORIMOTO, 2007);

0

20

40

60

80

100

128 B 256 B 512 B 1 KB 2 KB 4 KB 8 KB 16 KB0

200

400

600

800

1000

1200

Utiliza

ção do

Espaç

o em d

isco (po

rcenta

gem)

Tamanho do bloco (bytes)

Taxa d

e dado

s (KB/s

)

Utilização do Espaço em Disco Taxa de Transferência de Dados

16 REGISTRO MESTRE DE INICIALIZAÇÃO (MBR)

O MBR ainda hoje é o modelo mais utilizado para gerenciamento de boot de um disco. Feito para trabalhar em conjunto com o Sistema Básico de Entrada/Saída (BIOS), o MBR fica localizado no início do disco e possui tamanho máximo de 512 bytes, disponibilizados conforme a Tabela 3 (TECHNET, 2015).

Tabela 3: Setores do MBR Endereço Descrição Tamanho (em bytes)

+000h Código de Bootstrap 446 +1BEh Entrada da Partição 1 16 +1CEh Entrada da Partição 2 16 +1DEh Entrada da Partição 3 16 +1EEh Entrada da Partição 4 16

+1FEh ou +1FFh Assinatura de boot do disco 2

O MBR possui capacidade de gerenciar 4 partições primárias com até 2 TB, e não possui redundância. Com a substituição da BIOS pela Interface Unificada de Firmware Extensível (UEFI) o MBR começa a perder espaço para a GPT, porém ainda é mantido por questões de compatibilidade.

Tabela 4: Layout básico de uma tabela GUID Layout Básico de uma Tabela de Partição GUID

Master Boot Code MBR PROTETIVA

Entrada 1 da Tabela de Partição Entrada 2 da Tabela de Partição Entrada 3 da Tabela da Partição Entrada 4 da Tabela da Partição Cabeçalho da Tabela de Partição GUID

TABELA DE PARTIÇÃO GUID Entrada 1 da Partição GUID Entrada 2 da Partição GUID Entrada n da Partição GUID Entrada 128 da Partição GUID Partição Primária (C:)

PARTIÇÕES CRIADAS NO DISCO Partição Primária (D:) Partição Primária n Entrada 1 da Partição GUID

BACKUP DA TABELA DE PARTIÇÃO GUID

Entrada 2 da Partição GUID Entrada n da Partição GUID Entrada 128 da Partição GUID Backup Cabeçalho da Tabela de Partição GUID

TABELA DE PARTIÇÃO GUID (GPT)

Com o aumento dos discos, foi necessário criar um modelo de gerenciamento de arranque da máquina, e que fosse totalmente compatível com a Interface Unificada de Firmware Extensível (UEFI). Foi com esse intuito que surgiu a Tabela de Partição GUID (GPT), permitindo até 128

17 partições (dependendo do tamanho da GPT), contadores de setores de 64 bits (maior partição de 9,4 ZB), e redundância (a GPT pode ser encontrada no início e no final do disco).

A Tabela 4 ilustra um disco que utiliza o GPT. Mesmo não sendo mais necessário, o MBR ainda está presente num disco por motivos de compatibilidade, sendo o início do GPT fica no bloco adjacente, e ao final do disco uma cópia de seus dados são mantidas em caso de ocorrer alguma falha o início do disco. SUPERBLOCO OU BLOCOS DE PARÂMETROS DA BIOS

Superbloco, ou bloco de parâmetros da BIOS (BPB) como é chamado na documentação da Microsoft, é a primeira área do disco relacionada ao sistema de arquivos. Este bloco serve para armazenar algumas informações relacionadas ao sistema de arquivos da partição a qual ele pertence, como o “número mágico”, que contém um valor (em hexa) que informa ao sistema operacional qual o sistema de arquivos que deve ser utilizado para a montagem da partição. A Tabela 5 mostra alguns desses números mágicos.

Alguns sistemas de arquivos mais recentes, como o MINIX File System não possuem todos os dados do superbloco gravados em disco, já que vários deles são voláteis (exemplo a primeira inode livre, tamanho em disco, flag de somente-leitura, e versão do sistema de arquivos). Isso é feito como forma de proteção contra má escrita, pois um superbloco danificado acaba inutilizando toda a partição.

Tabela 5: Sistemas de arquivos e seus números mágicos Número Mágico Sistema de arquivos

0xEF53 Extended File System (EXT) 0x5346544E New Technology File System (NTFS) 0x4D5A MINIX File System V3 0x3153464A Journaling File System (JFS) 0x4D44 Sistema de Arquivos MSDOS 0x9123683E Better File System (Btrfs)

ESQUEMA DE ALOCAÇÃO DE DADOS

Alocar dados dentro de um disco não é uma tarefa fácil, muito menos manter essa alocação com o passar do tempo. Existem atualmente três técnicas bastante comuns utilizadas por sistemas de arquivos: alocação contígua, alocação encadeada e os inodes.

Figura 7: Exemplo de alocação contígua: 0x55 0x56 0x57 0x58 0x59 0x60 0x61 0x62

PART 1 (Begin)

PART 2 PART 3 PART 4 PART 5 (EOF)

PART 1 (Begin)

PART 2 PART 3 (EOF)

A alocação contígua faz com que um arquivo salvo em disco tenha seus blocos

armazenados de forma que todos estejam próximos. 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 gravação única (como o CD ou o DVD) este tipo de gravação é efetivo, pois, você garante que os arquivos jamais se fragmentarão, porém em dispositivos de armazenamento onde você tem certeza que os dados serão “voláteis” em um certo ponto, mais cedo ou mais tarde os dados se fragmentarão ou se perderão.

18 Figura 8: Exemplo de alocação encadeada

0x55 0x56 0x57 0x58 0x59 0x60 0x61 0x62 Begin NEXT: 0x56

NEXT: 0x61

Begin NEXT: 0x62

EOF NEXT: 0x60

EOF NEXT: 0x58

NEXT: 0x59

Na alocação encadeada continua possui a mesma ideia da alocação contígua: dados serão

armazenados de forma contígua, porém todos possuirão informação da localização do próximo bloco adjacente. A diferença é que, caso a partição fragmente, os dados ainda sim serão acessíveis, por outro lado existe uma perda enorme de desempenho pois quando um processo lê um bloco ele não precisa do cabeçalho, obrigando o sistema de arquivos a concatenar os blocos.

Figura 9: Exemplo da Tabela de Alocação de Arquivos

Uma solução apresentada é a que encontramos hoje nos sistemas de arquivos FAT: uma

tabela de alocação de dados que possui a localização de todos os arquivos em um único lugar. Dessa maneira o sistema de arquivos não precisa mais concatenar os dados antes de repassar para o processo. Porém a FAT obriga que a tabela inteira esteja na memória o tempo todo, o que pode ser um problema dependendo do tamanho do disco, a quantidade de arquivos presentes nele e o quanto de memória você tem disponível para uso.

Para solucionar o fato de manter a tabela todo o tempo na memória foram desenvolvidos os inodes, hoje utilizados por quase todos os sistemas de arquivos populares do Linux. Neste modelo, existe uma tabela na memória que armazena somente as entradas dos arquivos em uso no momento. Caso o arquivo seja fechado, a entrada é expurgada da memória, limitando a tabela somente ao limite máximo de arquivos que podem ser abertos simultaneamente pelo sistema operacional.

Com os inodes, além 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, porém caso precise de mais espaço são disponibilizados mais três blocos para uso de blocos de indireção.

Blocos de indireção são formados por um inode separado que possui X blocos, sendo X quem define é o sistema de arquivos. O primeiro bloco de indireção possui seu endereço no bloco 7, e caso seja preciso mais blocos disponíveis para este arquivo são utilizados os blocos de indireção dupla, que são X blocos que gerenciam X blocos cada. E se mesmo assim for preciso mais blocos, alguns

19 sistemas de arquivos disponibilizam os blocos de indireção tripla, onde são X blocos que gerenciam X blocos que gerenciam X blocos cada.

A Figura 10 demonstra melhor como funcionam esses blocos de indireção. Porém, após o uso de blocos de indireção tripla, o inode é considerado cheio, e um arquivo que utiliza mais do que um inode consegue gerenciar é considerado como muito grande e então descartado. Uma solução seria aumentar o número de blocos de indireção, porém não só não é vantajoso, como também esbarra no limite de ponteiros do sistema operacional.

Um sistema operacional 32 bits consegue gerenciar 2³²-1 ponteiros, isso caso sejam unsigned 5. Por conta desta limitação, durante muito tempo foi impossível gerar arquivos maiores que 4GB. A solução veio muito depois com o Large File Support (LFS), um conjunto de alterações feitas no kernel do Linux e na linguagem de programação 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 indireção

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 gravação de dados em disco, blocos são disponibilizados de forma sequencial a partir do início do disco com o intuito de diminuir o seek time, porém caso exista escrita/exclusão de dados com muita frequência no dispositivo, é possível que eles comecem a ficar esparsos na unidade, o que é chamado fragmentação de disco. Com o passar do tempo isso acarreta uma perda de desempenho, pois para um disco rígido é mais vantajoso ler blocos sequenciais do que ficar caçando seus fragmentos. Para evitar este cenário alguns sistemas de arquivos possuem um ou mais métodos de alocação de blocos anti-fragmentação, sendo os mais conhecidos: mballoc, fallocate e delalloc.

A Alocação de Multiblocos (mballoc), presente no EXT2 em diante, especula que pelo menos 8KiB serão gravados em discos, então reservará estes blocos para o arquivo. Caso estes blocos

5 Unsigned: Variável do tipo numérica sem sinal (RODRIGUES, 2013)

20 não sejam realmente utilizados após o fechamento do arquivo, então estes 8KiB serão devolvidos como disponíveis para a próxima requisição.

A Pré-Alocação (fallocate), presente no EXT3 e EXT4, somente inicia o processo de gravação após 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 solicitação. Se existir então eles são reservados e se dá o início da gravação. A pré-alocação não interfere com o tempo de escrita, já que não posterga a gravação.

Já a Alocação com Atraso (delalloc), ou Alocação Durante o Flush, é o método menos utilizado deles por ser o mais recente. Atualmente encontrado no XFS, Btrfs, e no EXT4, este método atrasa a gravação dos dados ao máximo possível, ao contrário do que é encontrado tradicionalmente que é “gravar os dados o mais cedo possível” (CALLEJA, 2011). Quando você atrasa a alocação dos blocos você acaba tirando a vantagem de conseguir armazenar da melhor forma possível arquivos cujo os dados estão em constate crescimento, além de evitar que arquivos temporários sejam escritos em disco. O tempo que se leva antes de iniciar a gravação é definido por três fatores:

O valor definido no campo commit_timeout durante a formatação (default é 5

segundos); Se o computador ficou com memória insuficiente durante a gravação 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 memórias 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 são os arquivos que estão abertos e quais processos estão utilizando eles.

A primeira tabela é a Tabela de Inodes Abertas, na qual é uma tabela que fica na memória e armazena os inodes de todos os arquivos que estão abertos. Esta tabela possui o tamanho igual ao número 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 estão utilizando. Quando este contador atinge 0, então a entrada é expurgada da memória.

A segunda tabela é a Tabela de Arquivos Abertos, ou Tabela FILP como é descrito por Tanenbaum (TANENBAUM & WOODHULL, Sistemas Operacionais: Projeto e Implementação, 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, porém com permissões 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 documentação do Linux (MAN, 2001), como padrão as entradas 0, 1 e 2 são sempre reservados para os arquivos de fluxos de entrada/saída padrão do sistema:

STDIN: Entrada padrão de dados, representado pelo descritor 0 sempre; STDOUT: Saída padrão de dados, representado pelo descritor 1 sempre; STDERR: Saída padrão 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 é responsável por executar uma busca em disco para encontrar o próximo bloco do arquivo que está sendo lido no momento. Mensagens são a maneira que o sistema de arquivos utiliza para se comunicar entre um processo solicitante e seus métodos. 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 laço principal que espera a chegada de uma mensagem. Quando chega uma mensagem, seu tipo é extraído e usado como índice em uma tabela contendo ponteiros para as funções dentro do sistema de arquivos que as manipulam. Então, a função apropriada é chamada, faz seu trabalho e retorna um valor de status. O sistema de arquivos envia, então, uma resposta para o processo que fez a chamada e volta para o início do laço para esperar a próxima 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 requisição para o sistema de arquivos não significa que ela será atendida na hora, e sim que será enfileirada e posteriormente tratada quando for mais conveniente.

Não responder a requisição também não 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 requisição e a enfileira, para então se libera para aguardar a próxima chamada.

22 Tabela 6: Algumas mensagens do sistema de arquivos

Mensagens Descrição Valor de Resposta chdir Altera o diretório de trabalho Status chmod Altera as permissões do arquivo/diretório Status chown Altera o usuário/grupo dono do arquivo Status creat Cria um novo arquivo em disco Descritor do Arquivo seek Busca pelo próximo bloco do arquivo no disco Nova Posição rename Renomeia o arquivo/diretório Status sync Grava todos os blocos alterados que estão em

cache Sempre OK umount Desmonta uma partição Status mount Monta uma partição Status mknod Cria um arquivo especial Status revive Revive um processo (Nenhuma resposta) read Lê o conteúdo de um arquivo Número de bytes lidos write Escreve um novo bloco ao final do arquivo Número de bytes escritos rmdir Exclui um diretório Status setuid Seta um novo valor para o usuário dono do

arquivo Status setgid Seta um novo valor para o grupo dono do

arquivo Status close Fecha um arquivo e exclui a inode dele da

memória Status

A Tabela 5 mostra algumas mensagens que são importantes, porém todas estão sujeitas a disponibilidade do sistema de arquivos. REGISTRO DE MUDANÇA (JOURNALING)

De acordo com Jones (2008), sistemas de arquivos com registro de mudanças (Journaling) são sistemas de arquivos resistentes a falhas que usam um diário que registra as alterações antes que elas sejam guardadas no sistema de arquivos para evitar que os metadados sejam corrompidos. Esses registros são armazenados numa área reservada pelo sistema de arquivos de até 15% do disco, e lá todas as alterações são salvas na forma de um diário. Caso ocorra uma falha de escrita, na próxima montagem a ferramenta de análise de disco do sistema operacional (fsck ou chkdsk) consultará este jornal e desfazer todas as últimas operações até que o disco esteja consistente de novo.

O registro de mudanças pode operar de três formas diferente:

Writeback Mode: Neste modo somente o metadado é salvo no jornal, enquanto os dados já são salvos diretos em suas áreas reservadas. Dessa forma você evita a corrupção do sistema operacional, porém possui uma grande chance do arquivo que você criou corromper durante a escrita em disco;

Ordered Mode: Neste modo continuamos salvando somente o metadado, porém ele só será adicionado ao jornal após confirmar que o arquivo foi escrito em disco. Isso evita a corrupção dos dados além do sistema de arquivos;

Data Mode: Considerado o modo mais seguro para ser utilizado, neste os dados e os metadados serão gravados no jornal, e após isso serão regravados em disco. Dessa forma você garante que quase nunca os dados corromperão, porém 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 espaço do

usuário (TANENBAUM & WOODHULL, 2008), recebendo todas as requisições 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, porém seu código cresceu tanto que está mais próximo 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 características desse sistema de arquivos são: 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 não possui uma versão sua 64bits oficialmente;

Tamanho máximo de arquivo: Capacidade de armazenamento de dados de no máximo 2 GB por arquivo, e possui como tamanho máximo de disco 4 TB;

Tolerância a falhas: possui mecanismos que dificultam falhas durante a gravação dos dados em disco, e também possui capacidade de restaurar os dados em caso de uma eventual falha;

Suporte a nomes de arquivos longos: possui suporte de até no máximo 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;

Segurança: O gerenciamento de permissões dos arquivos é baseado no documento POSIX6;

Figura 12: Composição de um disco com o MINIX FS

MINIX FILE SYSTEM Bloco de Boot Superbloco 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, porém com limitações conforme pode ser visto na Figura 13.

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

24 Figura 13: Exemplo do inode do MINIX FS

Modo Número de links

Uid Gid

Tamanho do arquivo Data de acesso

Data de modificação Data da modificação de status

Zona 0 Zona 1 Zona 2 Zona 3 Zona 4 Zona 5 Zona 6

Zona de Indireção Zona de Indireção Dupla

Sem uso Uma tabela dessas possui o tamanho máximo de 64 bytes, e ela é criada para cada novo

arquivo em disco. Conforme Tanenbaum (2008), essa região foi colocada por compatibilidade as normas da POSIX do que para algum uso do sistema operacional. Em seu código 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 indireção dupla. Num cenário desses não há necessidade de mais zonas de indireção.

Figura 14: Exemplo de um mapa de bits 0x55 0x56 0x57 0x58 0x59 0x60 0x61 0x62 0x63 0x64

1 1 1 0 0 1 0 0 1 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 localização de todos os inodes ou blocos, sejam eles livres ou em uso, e utiliza isso como uma forma de controle. Inclusão e exclusão de arquivos ocorre por meio da atualização dessa tabela. Informando que um determinado bloco desta tabela está em uso ou não é mais que o suficiente para que o sistema de arquivos saiba quais blocos disponibilizar para escrita.

Outro ponto da arquitetura é que o inode 0 não existe: ao contrário dos vetores que começam 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: Variáveis do tipo numéricas com sinais. (RODRIGUES, 2013)

25 X ou se existem inodes livres). Isso significa que, pelo menos, um inode não 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 próximo do final da lista ele estará. O controle de quantos processos estão requisitando determinado bloco é feito por meio de um contador. Quando este contador chega a zero significa que não existe mais nenhum processo requisitando ele, então o bloco pode ser seguramente descartado do cache.

Para controlar quais blocos estão no cache é utilizada uma segunda tabela a qual contém um hash de n bits de ordem inferior do bloco cacheado. Antes de executar uma operação de seek, o sistema de arquivos confere primeiro se o bloco já não se encontra cacheado, e somente caso não esteja é que executará uma operação de seek. Para agilizar o processo, o sistema de arquivos também cacheará o bloco seguinte, mesmo que não seja necessário.

SINCRONIZANDO BLOCOS

O MINIX não grava os blocos de imediato: ao invés disso ele a salva dentro do cache para posteriormente enviar a mensagem sync para gravar todos no disco. A chamada sync não 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 conteúdo diferente do disco.

2.4.2 PECULIARIDADES ENCONTRADAS

A seguir são descritos alguns problemas relatados pelos usuários ou até mesmos encontrados nas especificações do sistema. DESCONTINUIDADE

Conforme Tanenbaum (2010), existe um trabalho em conjunto para desenvolver um sistema de arquivos que possua tolerância a falhas. Como o seu código fonte também não é atualizado no Github8 desde Dezembro de 2014 é possível perceber que o sistema de arquivos não possuirá nenhuma nova release.

8 Github: site de compartilhamento de projetos Open Soure privados e públicos que permite versionamento e colaboração (GITHUB, 2015);

26 CÓDIGO INCOMPLETO E CONFUSO

Conforme pode ser visto no código fonte, e até mesmo escrito por Tanenbaum (2008), o sistema de arquivos MINIX possui trechos de código nele que não possuem uso nenhum. São partes que foram deixadas lá para posteriormente terem suas funções completadas por alguém que tivesse interesse nele. SEM RETROCOMPATIBILIDADE

Uma dessas funções que foram deixadas incompletas é justamente a compatibilidade com versões anteriores do sistema de arquivo. Vale ressaltar que este problema não ocorre com a versão mantida por Karel Zak no GitHub ou no repositório 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 distribuições Linux. Lançado em 2008 por uma equipe de programadores lideradas pelo desenvolvedor Theodore Ts'o, ele foi lançado com o intuito de ser o substituto do EXT3, que apresentava uma série de problemas de desempenho. É um sistema de arquivos de código aberto que funciona na camada de usuário utilizando dos recursos e vantagens proporcionados pelo Virtual File System Switch (VFS)9.

Entre as melhorias do EXT4 (DJWONG, 2014), as que podemos destacar são: Tamanho máximo de disco: o EXT4 possui como tamanho máximo 1EiB de disco e

consegue gravar arquivos de até 16 TiB; Gravação atrasada: para evitar a fragmentação, o EXT4 vem com a opção do

delalloc ativada por default; Modo No-Journaling: como default o EXT4 possui ativo o sistema de Journaling,

porém é possível desativa-lo caso não exista interesse em utiliza-lo. Em sua versão anterior (EXT3) o Journaling era obrigatório o uso;

Suporte a Extensões: Os inodes foram alterados para abandonar o uso dos blocos de indireção em favor das árvores de extensões, 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 verificação em todos os seus metadados;

Modo 48bits: No momento o EXT4 não possui e não precisa de suporte a 64bits, porém 32bits já não atendem mais as necessidades devido a limitação de criação de arquivos (maior arquivo 32bits é 4GB). Por isso, caso o sistema de arquivos tenha o modo 64bits habilitados, serão 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.

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

27 EXTENSÕES E ÁRVORES DE EXTENSÕES

A primeira e maior mudança feita no EXT4 é a maneira em que os blocos são armazenados em disco: a equipe abandonou o uso dos blocos de indireção a favor de uma estrutura chamada extensão. Extensões (extent) são formações de dados que são armazenadas de forma contínua no disco, conforme pode ser visto na Figura 16. Invés de você ter que utilizar uma entrada nos blocos de indireção para cada bloco escrito em disco, com as extensões você só precisa de um para cada conjunto de blocos que forem gravados de forma contínua. O resultado desta mudança é que agora o EXT4 possui capacidade de armazenar dados de até 16TiB.

Figura 16: Composição de um disco com o EXT4 FOURTH EXTENDED FILE SYSTEM

Grupo 0 Superbloco Descritor do

grupo Blocos

reservados Mapa de blocos

Mapa de inodes

Tabela de inodes

Dados Grupo 1

Superbloco Descritor do grupo

Blocos reservados

Mapa de blocos

Mapa de inodes

Tabela de inodes

Dados

Uma extensão pode armazenar o endereço de até 32768 blocos, porém nem todo esse espaço pode ser usado quando a extensão é alocada para um arquivo. É possível que, por causa do disco estar extremamente fragmentado ou o arquivo ser extremamente grande, mais extensões precisem ser disponibilizadas. Por padrão um inode do EXT4 possui 5 entradas para extensões, cada uma de 12 bits cada (60 bits), sendo 1 como cabeçalho, e as outras 4 para armazenar. Caso o arquivo venha a precisar de mais extensões então passamos a utilizar as árvores de extensões para armazenar estes arquivos.

Árvore de Extensões são árvore b+10que armazenam extensões em suas folhas. Essa árvore possui a profundidade máxima 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 regiões independentes, possuindo seus próprios mapas de inodes e blocos, e uma cópia 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 fragmentação.

A partir do EXT4 esta estrutura recebeu uma nova função, chamada de Grupo de Blocos Flexíveis, que possui a mesma ideia que o grupo de blocos normais, porém os mapas de inodes/blocos e o superbloco estarão localizados no início de cada grupo de bloco que seja um múltiplo de 3.

10 Á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);

28 Figura 17: Uma árvore de extensões

Fonte: (HSIUNG, 2009) Tabela 7: Conteúdo do cabeçalho das extensões

Offset Nome Descrição 0x0 eh_magic Número Mágico 0x2 eh_entries Número de extensões em uso 0x4 eh_max Número máximo de extensões disponíveis para esse inode 0x6 eh_depth Profundidade dessa extensão. Valor máximo de 5 0x8 eh_generator Geração dessa árvore. Sem uso para o EXT4 no momento

Tabela 8: Conteúdo dos nós das extensões

Offset Nome Descrição 0x0 ei_block Informa o range de blocos indexados por este nó 0x4 ei_leaf_lo Os últimos 32 bits que compõe uma extensão 0x8 ei_leaf_hi Os primeiros 16 bits que compõe uma extensões 0xA ei_unused Reservado para uma futura atualização

Tabela 9: Conteúdo das folhas das extensões

Offset Nome Descrição 0x0 ee_block O endereço do primeiro bloco armazenado nesta extensão 0x4 ee_len Número de blocos atendidos por essa extensão. 0x6 ee_start_hi Os primeiros 16 bits que essa extensão aponta 0x8 ee_start_lo Os últimos 32 bits que essa extensão aponta

INODES

Além da mudança dos blocos indiretos para extensões, os inodes do EXT4 também

passaram a ganhar alguns campos novos, sendo um deles o tão aguardado ctime, ou data de criação. O primeiro inode valido inicia a partir do 12, sendo os anteriores utilizados para gerenciamento. Eles

29 estão disponibilizados conforme apresentado na Tabela 10, ressaltando que por mais que seja dito que a inode 11 seja o primeiro inode disponível em disco, ainda sim já possui uma entrada por padrão. Tabela 10: Tabela de inodes reservadas

Inode Propósito 0 Utilizado como mensagem de erro de “Sem inode disponível” 1 Lista de blocos defeituosos 2 Diretório root 3 Quota de usuário 4 Quota de grupo 5 Bootloader 6 Diretório protegido contra exclusão 7 Reservado para uso futuro 8 Jornal 9 Reservado para uso futuro 10 Reservado para uso futuro 11 Primeiro inode livre. Utilizado pela pasta lost + founds

SUPERBLOCO

Diferente de outros sistemas de arquivos, como o MINIX FS, o EXT4 permite a edição do superbloco de forma a armazenar o maior número de informações possíveis dentro do espaço 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 segurança, o EXT4 possui uma cópia do superbloco no início de cada grupo de blocos presentes na partição. Caso a opção sparse_super esteja ativa, então o superbloco será salvo somente em grupos que sejam multiplos de 3 (Grupo de Blocos Flexíveis).

Tabela 11: Alguns campos do superbloco do EXT4 Offset Nome Descrição 0x0 s_inodes_count Contador do total de inode 0x4 s_blocks_count_lo Contador do total de blocos 0x20 s_blocks_per_group Blocos por grupo 0x28 s_inodes_per_group Inodes por grupo 0x2C s_mtime Tempo de montagem, em segundos desde o EPOCH 0x30 s_wtime Tempo de escrita, em segundos desde o EPOCH 0x34 s_mnt_count Quantidade de montagens antes de rodar o fsck 0x36 s_max_mnt_count Quantidade máxima de montagens antes de rodar o fsck 0x38 s_magic Número mágico

O número de informações armazenadas no superbloco do EXT4 também é bem maior,

sendo que é possível visualizar alguns destes campos na Tabela 11, porém 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. Graças a esta capacidade, a leitura se torna mais fácil, pois ao localizar o inode você tem acesso automaticamente ao arquivo sem a necessidade de executar posteriormente uma busca por seus blocos.

Existe uma alteração pendente no código que permitirá que seja possível armazenar até 160 bytes num inode, já que atualmente o sistema de arquivos gerencia de maneira incorreta o espaço utilizado por eles. POLÍTICA DE ALOCAÇÃO DE BLOCOS E INODES

A alocação dos blocos pelo EXT4 utiliza dos métodos mballoc, delalloc, fallocate, block group, e mais duas políticas de alocação. A primeira política é que todos os blocos de um mesmo arquivo serão salvos no mesmo grupo de blocos, se possível. Dessa forma diminui o seek time em disco já que toda a operação ocorrerá na mesma região do disco.

A segunda política implementada é que todos os inodes e arquivos serão salvos no mesmo grupo que seus diretórios. Esta política é válida para todos os grupos com exceção do grupo 0, que é responsável pelo conteúdo do diretório raiz. Caso uma pasta ou arquivo seja criada na raiz do sistema de arquivos, o conteúdo será salvo no grupo que estiver com menos uso.


A seguir são descritos alguns problemas relatados pelos usuários ou até mesmos

encontrados nas especificações do sistema. PERDA DE DADOS

Muito reclamado pela comunidade, e até levantado em algumas discussões pelo Linus Torvalds (2009), devido as novas políticas de gerenciamento de blocos do EXT4, a gravação de dados pode levar algo em torno de 30 a 60 segundos. Um valor intolerável para muitos, visto que em alguns casos 60 segundos pode ser uma perda significante de dados. Como solução de contorno foi liberado a opção de montagem nodelalloc, que permite desabilitar a alocação com atraso.

DOCUMENTAÇÃO OFICIAL PRECÁRIA

O EXT4 possui uma wiki11 que possui o material oficial sobre sua estrutura e design. Porém boa parte do conteúdo é encontrada de forma incompleta por falta de conhecimento de quem estava escrevendo, e conteúdo desatualizado, já que algumas páginas não citam as funções acrescentadas no código esse ano.

SISTEMA DE ARQUIVOS 48bits

O EXT4 foi desenvolvido utilizando da união de dois ponteiros para que seja possível gerenciar blocos acima de 32bits, porém mesmo com todo esse poder de armazenamento a comunidade 11 Wiki: é utilizado para identificar qualquer coleção de documentos;

31 de desenvolvedores informa que esse valor é teórico e não 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 família de sistemas operacionais Windows NT, e desde então é o sistema de arquivos principal de todas as versões do Windows. É um programa de código fechado que funciona na camada de kernel, recebendo as requisições dos processos, executando, e então repassando a mensagem de volta ao solicitante.

Entre as melhorias do NTFS, as que podemos destacar são: Capacidade de armazenamento: Possui capacidade teórica de receber 16TiB (com

clusters de 64kb) como maior arquivo, e gerência partições de até 256TiB; Segurança: O NTFS utiliza Listas de Controle de Acesso (ACL) como meio de

gerenciar qual usuário/processo tem acesso a determinado arquivo e quais são suas respectivas permissões;

Nomes de arquivos logos: suporte a até 256 caracteres, isso excluindo as extensões; Gerenciamento de arquivos com MFT: a localização de arquivos, como também o

uso de clusters é feito através de uma Tabela Mestre de Arquivos (MFT), que por sua vez é uma evolução 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 cópia da Tabela Mestre de Arquivos.

Figura 18: Composição de um disco com o NTFS NEW TECHNOLOGY FILE SYSTEM

Setor de boot

Tabela Mestre de Arquivos Dados Backup da Tabela

Mestre de Arquivos CLUSTER

Cluster é a menor unidade dentro da partição do NTFS, e funciona da mesma maneira que um bloco. O NTFS possui capacidade de gerenciar em uma única partição 2³² cluster menos 1, e o valor default de alocação de clusters varia de acordo com o tamanho da partição, conforme pode ser visto na Tabela 12.

Tabela 12: Valores padrão 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 partição no setor de boot, ao contrário dos demais sistemas de arquivos. Essa partição possui o tamanho de até 16 setores (8KB) e consiste dos seguintes elementos:

Uma instrução de jump para CPU baseada na arquitetura x86; O identificador original de fabricante do equipamento (OEM ID); O Bloco de Parâmetros da BIOS; Extensões do BPB; O código executável que inicia o sistema operacional;

Ao final do setor de boot da partição pode ser localizado a assinatura do sistema de

arquivos, que é 0x55AA. Na Tabela 13 é possível conferir alguns dos campos encontrados dentro do bloco de parâmetros. O campo 0x30 (Número do Cluster do MFT) é utilizado para definir a localização do MFT, dessa forma permitindo que seja alocado para outra região, caso a atual possua algum setor defeituoso.

Tabela 13: Bloco de parâmetros da BIOS Byte Offset Nome do Campo Descrição

0x0B Bytes por Setor Tamanho de um setor do disco. 0x0D Setor por Cluster Número de setores em um cluster. 0x0E Setores reservados Por padrão o valor sempre deve ser 0 para designar a

região aonde se encontra o setor de boot. 0x15 Descritor de mídia

Informa qual o tipo de mídia que armazena essa partição. F8 significa que se trata de um “Hard Disk”, enquanto F0 significa “Floppy Disk” .

0x28 Total de Setores Número total de setores no disco 0x30 Número do Cluster do

MFT Informa a localização do MFT em disco. 0x44 Clusters para buffer de

index Informa o tamanho de cada buffer de index, na qual são utilizados para alocar espaço para diretórios.

MASTER FILE TABLE (MFT)

A Tabela Mestre de Arquivos (MFT) foi criada como uma evolução da Tabela de Alocação de Dados do FAT16. Ela possui o tamanho equivalente a 12,5% do tamanho total do disco, porém pode ser ajustado para as seguintes configurações:

Configuração 1 ou Default: Reserva 12,5% do disco para a tabela; Configuração 2: Reserva 25% do disco para a tabela; Configuração 3: Reserva 37,5% do disco para a tabela; Configuração 4: Reserva 50% do disco para a tabela;

33 Vale ressaltar que essa configuração é feita de forma automática pelo NTFS, sendo que ele

se auto reconfigurará assim que notar que a tabela atingiu seu tamanho máximo. Nesse caso é possível que a tabela acabe se fragmentando, já que as demais partes serão alocadas em regiões diferentes do disco de acordo com a disponibilidade. Também é possível configurar durante a formatação o tamanho reservado para a MFT, dessa forma é possível evitar a fragmentação da tabela, porém você perde espaço em disco para os registros.

A MFT reserva os primeiros 16 registros para seus próprios metadados, sendo eles distribuídos conforme a Tabela 14. Cada registro dentro da MFT possui o tamanho de 1KB e armazenam alguns dados básicos sobre o arquivo, como o nome dele. Dentro de um registro da MFT, 900 bytes são reservados para:

Registros Residentes: Quando um arquivo possui um tamanho menor que 900 bytes

então 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 são armazenados dentro da entrada do MFT;

Tabela 14: Entradas Reservadas para o MFT

Arquivo do Sistema Nome do Arquivo Objetivo Master file table $Mft Cabeçalho do MFT Master file table mirror $MftMirr Cópia do arquivo $Mft para caso do primeiro

ser danificado Log file $LogFile

Contém informações sobre as alterações pendentes, para no caso de ocorrer uma parada no sistema operacional

Volume $Volume Contém informações sobre o volume Attribute Definitions $AttrDef Lista de nomes de atributos, números, e

descrição Root file name index . A pasta root (C:\) Cluster bitmap $Bitmap Informa quais os clusters livres e quais estão

em uso pelo volume Boot sector $Boot Armazena informações sobre o bloco de boot Bad cluster file $BadClus Contém uma lista de todos os clusters

danificados no volume Security file $Secure Descritores de segurança para todos os

arquivos em disco Upcase table $Upcase Converte letras minúsculas para serem

compatíveis com os caracteres maiúsculo NTFS extension file $Extend Usado para extensões do NTFS, como quotas,

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 é possível 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, porém com algumas diferenças: não são 3 tabelas, e sim 1 só que é mantida pelo próprio sistema de arquivos. Cada arquivo possui sua própria tabela de descritores, formada por dois tipos de descritores: os descritores de dados sem nome, e os descritores de dados com nome. A única diferença entre ambos é que os sem nome são utilizados para funções internas do sistema operacional, enquanto os descritores com nomes são disponibilizados para os processos controlarem aonde estão acessando o arquivo.

Tabela 15: Atributos do MFT Byte Offset Nome do Campo Descrição

0x0B Bytes por Setor Tamanho de um setor do disco. 0x0D Setor por Cluster Número de setores em um cluster. 0x0E Setores reservados

Por padrão o valor sempre deve ser 0 para designar a região aonde se encontra o setor de boot.

0x15 Descritor de mídia Informa qual o tipo de mídia que armazena essa partição. F8 significa que se trata de um “Hard Disk”, enquanto F0 significa “Floppy Disk12” .

0x28 Total de Setores Número total de setores no disco 0x30 Número do Cluster do MFT Informa a localização do MFT em disco. 0x44 Clusters para buffer de index

Informa o tamanho de cada buffer de index, na qual são utilizados para alocar espaço para diretórios.


A seguir são descritos alguns problemas relatados pelos usuários ou até mesmos

encontrados nas especificações 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 atualização foi no lançamento do NTFS 5 (Windows 2000). A Microsoft a anos tenta desenvolver um sistema de arquivos superior a ele, porém o projeto é sempre cancelado. Atualmente existe um esforço para desenvolver o ReFS (Resilient File System) para que seja lançado na próxima versão do Windows Server, com o intuito de solucionar diversos problemas relatados pelos usuários. SEM TOLERÂNCIA A FALHAS

O NTFS possui modelos para se recuperar após falhas, como o Journaling, porém não é um sistema de arquivos que consegue contornar falhas. Também existem reclamações dos usuários referente a perda de dados da versão do NTFS do Windows 10. 12 O NTFS não possui suporte a disquetes, sendo esse campo meramente um resíduo do FAT16. (TECHNET, 2003)

35 TABELA MESTRE DE ARQUIVOS NA MEMÓRIA

Outro ponto negativo, esse herdado do FAT16, é que o NTFS precisa que toda sua tabela de arquivo esteja em memória. 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 capítulo serão 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 código aberto baseado na arquitetura UNIX, desenvolvido por Andrew Stuart Tanenbaum (TANENBAUM & WOODHULL, Sistemas Operacionais: Projeto e Implementação, 2008) e mantido pela comunidade. Iniciou como uma ferramenta educacional para seu livro “Sistemas Operacionais – Projeto e Implementação”, porém desde o lançamento a terceira versão do sistema, em 2005, o desenvolvimento tem sido focado para dar suporte a aplicações baseadas em processadores ARM. Mesmo não sendo mais seu foco, o MINIX continua sendo uma excelente ferramenta para estudos.

3.2 UBUNTU SERVER

Ubuntu Server é uma ramificação da distribuição Ubuntu, mantido pela Canonical, voltado para servidores. Em sua 15º versão (Vivid Vervet), o Ubuntu possui como diferencial o fato dos pacotes estarem sempre na versão mais recente, diferente das demais distribuições no mesmo ramo que lançam somente atualizações de correção. O Ubuntu também é conhecido por possuir a maior quantidade de pacotes compatíveis com o sistema operacional.

3.3 MICROSOFT WINDOWS 10 PRO

O Microsoft Windows é um sistema operacional pago de código fechado, desenvolvido

pela Microsoft, com foco em usuários de desktops ou notebooks. Lançado em 2015, o Windows 10 veio com uma série de novas funcionalidades e correções visuais, comparado ao seu antecessor, o Windows 8.1. Entre elas o suporte ao Cortana e a volta do menu Iniciar. Apesar de não possuir nenhuma atualização 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 gênero (como o cp) é que com o dd você pode copiar qualquer coisa, como uma unidade de disco inteira, além de ser possível também gerar arquivos com conteúdo randômico.

Os parâmetros aceitos pelo dd que foram utilizados nos testes são: • if: Informa o arquivo de origem que pretende copiar; • of: Informa o arquivo de saída que receberá o conteúdo; • bs: Informa o tamanho dos blocos alocados dentro do arquivo; • count: Informa quantas vezes a operação será repetida; • conv: Permite passar um parâmetro de como o dd deve ser executado. Nos testes será

utilizado o parâmetro fdatasync, que desabilita a alocação com atraso;

37 Figura 19: Exemplo do dd após a execução

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 aplicações em um ambiente isolado, antes de colocarem eles em produção. 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 histórico de estabilidade e desempenho.

O VMware possui compatibilidade com o MINIX, Ubuntu Server, e Windows 10 virtualizados. Abaixo segue as configurações de hardware das máquinas virtuais:

• 1 vCPU; • 1 GB de Memória RAM; • Hard Disk de 60 GB (Necessário principalmente para o Windows);

38 4. REALIZAÇÕES DE TESTES

Neste capítulo serão discutidos sobre os testes de carga realizados através do dd e análise

comportamental dos discos.

4.1 TESTE DE CARGA

A execução do dd nas máquinas virtuais foi realizado de duas formas: a primeira pegando o tempo de criação de um único arquivo, e depois o tempo de criação de múltiplos arquivos. Você pode conferir os tempos de criação nos gráficos abaixo. Executar os testes com o dd se provou desafiador devido aos relatórios de tempo saírem de forma inconsistente. Isso ocorre em ambientes virtuais com facilidade devido a máquina virtual competir a escrita com outras máquinas virtuais e também com o próprio sistema operacional hospedeiro (no caso o Windows 10).

4.1.1 CRIAÇÃO DE UM ÚNICO ARQUIVO

Figura 20: Criação de um único arquivo via dd

Durante a primeira etapa dos testes, o MINIX FS se saiu relativamente bem até começar a

utilizar os blocos de indireção dupla, quando o tempo de criação passou a crescer conforme o arquivo também crescia. Isso ocorre porque o MINIX ainda utiliza a antiga função de alocação de blocos “balloc”, aonde é alocado bloco a bloco no disco. Já o NTFS e o EXT4 tiveram desempenhos semelhantes, sendo o NTFS mais rápido por questão de segundos. Isso ocorre pois ambos trabalham com alocação de Multiblocos, além de que as mudanças na MFT e na Inode de cada um com o objetivo de melhorar o desempenho se provaram efetivas.

4.1.2 CRIAÇÃO DE MÚLTIPLOS ARQUIVOS (1 MB)

Ao executar o loop de criação de arquivos, o dd teve o melhor desempenho do EXT4,

1 MB 10 MB 100 MB 500 MB 1 GB 2 GB0

20406080

100120140160180

Tamanho do Arquivo

Tempo

(em seg

undos)

Minix FS V3EXT4NTFS

39 levando até 128 segundos para criar 16000 arquivos em disco, porém 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: não conseguiu eliminar esses arquivos posteriormente. Na tentativa foi alegado falta de memória, mesmo que outras ferramentas (free ou o top) informassem o contrário.

O NTFS não teve problemas para excluir os arquivos, também não sofreu de instabilidade, porém o tempo de criação foi o maior dos testes: 534 segundos para concluir a atividade.

Figura 21: Criação de multiplos arquivos via dd (1 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 também 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, porém dessa vez o tempo de criação caiu para 336 segundos, como pode ser visto na Figura 24. Não teve problemas para excluir os arquivos após a criação. O EXT4 manteve seu desempenho, porém ainda apresentando instabilidade na criação dos arquivos, possuindo tempo de criação semelhante entre 800 arquivos e 1200 arquivos. Já o NTFS possui um tempo de criação melhor com arquivos de 10 MB do que com arquivos de 1MB. Com a mesma quantidade de informações sendo armazenadas, 16 GB de arquivos de 10 MB levaram 82 segundos para serem escritas em disco.

1000 2000 4000 8000 12000 160000

100

200

300

400

500

600

Quantidade de Arquivos

Tempo

(em seg

undos)

Minix FS V3EXT4NTFS

40 Figura 22:Criação de multiplos arquivos via dd (10 MB)


Figura 23: Criação de multiplos arquivos via dd (100 MB)

Novamente é perceptível um aumento de desempenho conforme o tamanho dos arquivos

também aumenta, porém, os tempos do MINIX continuam inferiores aos do EXT4 e do NTFS. Novamente o EXT4 sofre de intermitência do tempo de criação, possuindo um péssimo tempo ao criar 20 arquivos de 100 MB, porém 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. É

100 200 400 800 1200 16000

50100150200250300350400


Tempo

(em seg

undos)

Minix FS V3EXT4NTFS

10 20 40 80 120 1600

50

100

150

200

250

300

350


Tempo

(em seg

undos)

Minix FS V3EXT4NTFS

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 CRIAÇÃO DE MÚLTIPLOS ARQUIVOS (1 GB)

Figura 24: Criação de multiplos arquivos via dd (1GB)

Criar arquivos grandes (+ 1 GB) demonstra que por mais que o MINIX possua capacidade

para tratar eles, não foi feito com esse propósito. Mesmo com arquivos pequenos ainda existia uma perda de desempenho comparado ao NTFS e o EXT4, e o aumento do tamanho não mudou muita coisa. O EXT4 e o NTFS possuíram tempo de armazenamentos semelhantes, porém 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 CONCLUSÕES

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 também podem ser consideradas obsoletas. Já o EXT4 possui um desempenho aceitável, porém possui uma instabilidade de desempenho causado pelo próprio sistema de arquivos que monitora o melhor momento para armazenar, dessa forma não se sobrecarregando de tarefas. O NTFS, por outro lado, conseguiu manter os tempos de maneira estável, porém tem um péssimo desempenho quando se trata de arquivos pequenos.

4.2 USO DO SISTEMA DE ARQUIVOS

Nesse tópico serão discutidos sobre os sistemas de arquivos em produção, como o comportamento deles em ambiente de produção, entre outros.

1 2 4 8 12 160

50

100

150

200

250

300

350


Tempo

(em seg

undos)

Minix FS V3EXT4NTFS

42 4.2.1 MINIX FS V3

O MINIX FS não é tão diferente quanto outros sistemas de arquivos UNIX-like, com o

EXTFS, XFS, ou o JFS. Ele possui suporte a alguns metadados de arquivos, não ocupa tanto espaço 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 compreensão, porém para uso não é tão bom assim. As limitações de 2GB para o tamanho máximo 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 não 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 contrário dos demais que armazenam primeiro.

A incompatibilidade do sistema de arquivos com suas versões anteriores também complica caso deseje migrar os dados. Sua melhor chance é criar uma partição EXT2 e então armazenar os dados nessa partição. Esse problema já foi solucionado na versão do LINUX do MINIX FS, porém a versão do LINUX não sabe gerenciar blocos maiores do que 64KB. Na melhor das possibilidades, o MINIX é perfeito para usar em dispositivos pequenos, como disquetes, ou para estudos. Porém para o uso do dia a dia existem melhores.

4.2.2 FOURTH EXTENDED FILE SYSTEM (EXT4)

O EXT4 foi desenvolvido para ser a versão mais robusta do EXT3, que havia sido apresentado como uma solução para os problemas do EXT2, porém no fim acabou criando outros, em principal a perda de desempenho causada pelo Journaling. A ideia de substituir o modelo de alocação de blocos indiretos por extensões funcionou perfeitamente, sendo que agora possui suporte a arquivos grandes, muito mais do que seu antecessor suporta.

Outro ponto é a inclusão de novas políticas de alocação de dados, como o delalloc. Isso mitigou muito a fragmentação de dados, já que agora o sistema de arquivos espera ao máximo pelo melhor momento antes de alocar os arquivos em disco. Outro diferencial é que agora é possível formatar uma partição sem o Journaling, o que aumenta o espaço e o desempenho, em troca da resiliência.

Por outro lado, o EXT4 tem sofrido por causa de seus problemas, principalmente com a alocação com atraso. Existem casos em que a alocação com atraso não respeita o “commit_timeout”, ocasionando em perda de dados, e outras em que o usuário gostaria de usufruir dos recursos do EXT4, porém não quer arriscar a perda de 60 segundos de dados, motivo pelo qual posteriormente foi criado a opção de montagem “nodelalloc”.

Outros problemas vistos são dentro da própria comunidade, aonde existe uma briga entre aqueles que apoiam os recursos do EXT4, e aqueles que são contra eles. Isso tem afetado muito a imagem do sistema de arquivos, ao ponto de algumas empresas cogitarem a substituição dele por outro, como por exemplo o Btrfs.

4.2.3 NEW TECHNOLOGY FILE SYSTEM (NTFS)

O NTFS pode não aparentar ser tão velho, porém dos 3 é o sistema de arquivos mais antigo. Foi desenvolvido no ano de 1993, e de lá para cá não sofreu muitas alterações para inclusão de novas funções, porém possui a maior estabilidade entre os três. Sua última grande mudança foi o lançamento do NTFS 5, que foi lançado junto com o Windows 2000. O foco dele é servidores, então toda sua

43 estrutura foi feita para atender essa demanda desde aquela época, porém como desktops também precisavam abandonar o FAT16, então o mesmo sistema de arquivos é utilizado para máquinas clientes.

O sistema de arquivos possui abordagens interessantes, como a tabela de descritores de arquivos ser simplificada em 1 única por arquivo, porém é tão simplista quanto o MINIX FS. Por ser um sistema de arquivos antigo, era de se esperar que já tivesse sido substituído por outro, porém a Microsoft não 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 memória, o que pode ser um problema dependendo do tamanho total da tabela e o quanto de memória você possui. Outro ponto negativo é a falta de documentação do NTFS, sendo que a maioria encontrada é bem rasa, com exceção de alguns feitos por fãs que são bem detalhados, ou uma documentação ou outra da Microsoft. E mesmo esses documentos estão desatualizados, com por exemplo a TechNet (2003) que a última atualização foi em 2003.

O último ponto não chega a ser negativo, e sim curioso. O NTFS possui o bootloader já instalado na partição, mesmo que ela não seja inicializável. Na documentação é informado que a região é livre caso não seja inicializável, porém ao formatar um disco com o NTFS foi possível notar o bootloader nos primeiros 1024 bytes do disco.

44 5. CONSIDERAÇÕES FINAIS

O objetivo final desse trabalho foi realizar um estudo em três sistemas de arquivos

diferentes com o intuito de compreender seu funcionamento. Para conseguir atingir esse objetivo foi necessário um estudo inicial de como os sistemas de arquivos funcionam, levantando toda a parte teórica das funcionalidades sem focar em um único sistema de arquivos. Com essas informações foi possível então compreender como cada um dos sistemas de arquivos apresentados se comportam.

Diversos problemas foram encontrados ao longo do tempo, como a falta de material didático para alguns dos sistemas de arquivos, ou ferramentas que fossem compatíveis 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 não interferisse nela. Máquinas 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, porém ainda existe campo a ser explorado dentro desse tema. Durante o projeto foi levantado diversas ideias do que mais poderia ser explorado, porém pela falta de tempo tiveram que ficar de fora.

45 6. LISTA DE ABREVIAÇÕES

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. REFERÊNCIAS

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, disponível em

https://latedev.wordpress.com/2012/12/04/all-about-eof CALLEJA, D. (2008). EXT4. Acesso em 13 de nov. de 2015, disponível 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, disponível em

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout GITHUB. (2015). About GitHub. Acesso em 18 de ago. de 2015, disponível em

https://github.com/about HARRIS, M. (2010). What is a B+ Tree? Acesso em 27 de set. de 2015, disponível 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-tree-for-larger-files.png

IDEMA. (2011). Advanced Format (AF) Technology. Acesso em 8 de nov. de 2015, disponível 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, disponível 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, disponível em http://www.ibm.com/developerworks/br/library/l-journaling-filesystems/

JUNIOR, P. G. (2015). Trabalhando com o sistema de arquivos NTFS - Parte I. Acesso em 30 de set. de 2015, disponível 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, disponível em http://windows.microsoft.com/pt-br/windows-vista/comparing-ntfs-and-fat-file-systems

MISTWIZ. (2008). Disk-structure2.svg. Fonte: https://upload.wikimedia.org/wikipedia/commons/a/ae/Disk-structure2.svg

MORIMOTO, C. E. (2007). Disco Rígido. Acesso em 15 de out. de 2015, disponível em http://www.hardware.com.br/termos/disco-rigido

RODRIGUES, G. (2013). Modificadores de Variáveis. Acesso em 18 de out. de 2015, disponível 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, disponível em http://content.time.com/time/specials/packages/article/0,28804,1999143_1999210_1999211,00.html

47 TANENBAUM, A. S. (2010). MINIX 3: status report and current research. Acesso em 30 de out. de

2015, disponível em http://www.minix3.org/docs/login-2010.pdf TANENBAUM, A. S., & WOODHULL, A. S. (2008). Sistemas Operacionais: Projeto e

Implementação. Bookman. TECHNET. (2003). How NTFS Works. Acesso em 30 de set. de 2015, disponível 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, disponível em

https://technet.microsoft.com/en-us/library/cc976786.aspx WOLSKI, R. (2014). filetable.rich.jpg. Acesso em 5 de dez de 2015, disponível em

http://www.cs.ucsb.edu/~rich/class/cs170/notes/FileSystem/filetable.rich.jpg

Documents

Sistemas de Arquivos