Camada De Rede

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

Aluna: Danielly Karine da Silva Cruz ([e-mail])

Orientador: Sérgio Vanderlei Cavalcante ([e-mail])

Índice

ÍNDICE 2

RESUMO 3

AGRADECIMENTOS 4

1 INTRODUÇÃO 5

2 TRABALHOS RELACIONADOS 6

2.1 NACHOS 6

2.2 MINIX 6

2.3 AMOEBA 7

2.4 RCOS-JAVA 7

3 RCOS-JAVA 8

4 SISTEMA DE ARQUIVO 12

4.1 ARQUIVO 12

4.1.1 Qual a importância 12

4.1.2 Atributos dos Arquivos 12

4.1.3 Estrutura do Arquivo 13

4.1.4 Tipos de Arquivo 14

4.1.5 Operações sobre Arquivos 16

4.1.6 Arquivos mapeados na Memória 16

4.2 DIRETÓRIO 17

4.2.1 Organização do Sistema 18

4.3 IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVO 19

4.3.1 Implementação de Arquivos 20

4.3.2 Tipos de implementação de arquivo 20

4.4 IMPLEMENTAÇÃO DE DIRETÓRIO 21

4.4.1 Tipos de implementação de diretório 21

4.4.2 Algoritmo de busca no diretório 22

5 MS-DOS 23

5.1 HISTÓRIA DO MS-DOS 23

5.1.1 O PC IBM 23

5.1.2 MS-DOS Versão 1.0 25

5.1.3 MS-DOS Versão 2.0 25

5.1.4 MS-DOS Versão 3.0 26

5.1.5 MS-DOS Versão 4.0 26

5.1.6 MS-DOS Versão 5.0 26

5.2 O SISTEMA DE ARQUIVO 27

6 O SISTEMA DE ARQUIVO PROPOSTO PARA O RCOS 31

6.1 DESENVOLVIMENTO DO SISTEMA DE ARQUIVO DO RCOS 31

6.2 DIAGRAMA DE CLASSE 31

6.3 ESTRUTURAS PRINCIPAIS 33

6.3.1 Diretório 33

6.3.2 FAT 34

6.3.3 Disco 35

6.3.4 Interface 36

6.3.5 Gerenciador do Sistema de Arquivo 37

6.3.6 Arquivo do Sistema de Arquivo 40

6.4 DECISÕES DE PROJETO 40

6.5 PROBLEMAS ENCONTRADOS 42

6.6 UTILIZANDO O SISTEMA DE ARQUIVO DO RCOS 42

7 CONCLUSÃO 44

8 TRABALHOS FUTUROS 45

REFERÊNCIAS E BIBLIOGRAFIA 46

DATA E ASSINATURAS 48

Resumo

Sistema Operacional é um software importante do computador que controla todos os seus recursos. Os aplicativos que criamos como programadores são executados sobre o sistema operacional, e é importante conhecer como ele funciona para termos a base necessária para desenvolver programas mais rápidos e confiáveis.

Sabemos que é importante conhecer o sistema operacional, mas ele é em geral complexo e extenso por gerenciar vários módulos. Assim, há uma procura por métodos para um melhor entendimento dos vários tópicos relacionados ao SO. A fim de ajudar nesse sentido surgiram nas últimas duas décadas vários softwares educacionais e de código aberto.

O RCOS-java (Ron Chernich's Operating System) é um software educacional e de código aberto para entender como funciona o sistema operacional internamente. O RCOS pretende explicar várias partes do SO. Porém o módulo de gerenciamento de disco e sistema de arquivo ainda não se encontram implementados. A proposta deste trabalho foi desenvolver o módulo de ensino sobre sistema de arquivo baseado no do MS-DOS, estendendo assim o RCOS.

Agradecimentos

Este projeto foi bastante difícil de ser implementado, por diversas razões, no entanto consegui finalizá-lo graças à colaboração de diversas pessoas.

Gostaria de agradecer primeiramente a minha família, e em especial à minha mãe Célia Maria por todo apoio e incentivos dados durante toda minha vida acadêmica, principalmente durante esta etapa final de minha formação profissional.

Meu especial agradecimento vai para meu orientador Sérgio Cavalcante que aceitou em orientar no trabalho de graduação, a Marcelo Nery, Leonardo Cole e Paulo Abadie que me ajudaram tirando dúvidas, a Amanda Pimentel que leu meu documento cuidadosamente, e a todos que me deram suporte direta ou indiretamente no decorrer da elaboração deste trabalho.

1 Introdução

Sistema Operacional é um software importante do computador que controla todos os seus recursos, ele realiza ações como ativação e gerenciamento de memória ou controle dos dispositivos de entrada e saída. Fornece a base sobre a qual os programas aplicativos são executados. Os softwares como Word e Excel só podem rodar sobre um sistema operacional, ou seja, sobre uma plataforma de suporte. As plataformas mais famosas são o Windows, MacOS (sistema operacional do Macintosh), o MS-DOS e o Linux.

Os aplicativos que criamos como programadores são executados sobre o sistema operacional, e é importante conhecer como ele funciona para termos a base necessária para desenvolver programas mais rápidos e confiáveis, tirando bom proveito do que o sistema pode nos oferecer. Caso nossos aplicativos tenham algum problema como estouro de pilha poderemos saber que resolveremos comprando mais memória ou gerenciando melhor a mesma.

Sabemos que é importante conhecer o sistema operacional, mas ele é em geral complexo e extenso por gerenciar vários módulos. Há uma grande dificuldade também relacionada à compreensão dos conceitos e abstrações tais como entender o que é processo ou concorrência. Assim, há uma procura por métodos para um melhor entendimento dos vários tópicos relacionados ao SO. A fim de ajudar nesse sentido surgiram nas últimas duas décadas vários softwares educacionais e de código aberto. Estes SOs são usados como instrumento de ensino nas universidades para um estudo mais amplo, aprofundado e prático dos conceitos de um sistema operacional já que o ensino é feito por exemplos e experimentos. Exemplos destes sistemas educacionais são o Nachos [6,8], o Minix [1,2], o Amoeba [3,4] e o RCOS (Ron Chernich's Operating System) [9,10]. Este trabalho se baseia no sistema RCOS.

O RCOS-java é um software educacional e de código aberto para entender como funciona o sistema operacional internamente e é baseado na versão anterior do mesmo, escrita em C++. O seu desenvolvimento começou em 1996 por quatro pessoas da Universidade Central do Queensland, Austrália. Ele é um software interessante por ter interface gráfica e multitarefa, que simula um sistema operacional. O RCOS pretende explicar várias partes do SO como escalonamento de processos (dependendo do algoritmo de ordenação de fila e quantum), comunicação entre processos e as instruções de código da CPU. Porém o módulo de gerenciamento de disco e sistema de arquivo ainda não se encontram implementados.

A proposta deste trabalho é desenvolver o módulo de ensino sobre sistema de arquivo, estendendo assim o RCOS. Na proposta inicial do RCOS, este deveria basear-se no sistema arquivo do SO CP/M por ser simples. O módulo desenvolvido foi baseado no sistema do MS-DOS 5.0, o qual apesar de antigo é ainda hoje utilizado.

O documento inicialmente mostra os trabalhos relacionados no capítulo 2. Falamos do software de ensino RCOS escolhido. Damos uma visão geral sobre arquivo e sistema de arquivo no capítulo 4. No capítulo 5 vemos o MS-DOS e no 6 o desenvolvimento do projeto.

2 Trabalhos Relacionados

Existem vários sistemas operacionais que vem sendo utilizados para ensino, como o Linux; porém alguns formam desenvolvidos especificamente para este fim como o Nachos e o RCOS, os quais apenas simulam como os sistemas operacionais funcionam. Nesta seção serão mostrados alguns desses softwares.

2.1 Nachos

Software Acadêmico desenvolvido inicialmente em C++ que está sendo portado para Java (linguagem orientada a objeto e multiplataforma). A proposta do Nachos [6,8] é ser um SO de código aberto para ensino, e real o bastante para um aluno poder entendê-lo e alterá-lo de maneira significativa. O mesmo vem com um conjunto de atividades propostas para os alunos desenvolverem. Ele inclui uma CPU e simuladores de dispositivos, é executado como um processo UNIX normal e aciona o simulador quando precisa utilizar dispositivos físicos ou executar comandos do usuário.

Nachos inclui gerenciamento de threads, sistema de arquivo, multiprogramação, memória virtual e rede. O Nachos 4.0 usa assembly (não portável) para suportar multithreading. O mesmo tem 2500 linhas de código, das quais aproximadamente metade é de descrição das interfaces das funções e comentários. Ele foi projetado para a rodar em estações DEC MIPS. Na versão java do Nachos não está implementada a parte de disco.

O Nachos tem muitas desvantagens como: é difícil de instalar, complicado de usar e executar os exemplos, não tem interface gráfica e código complexo, por tentar ser real o bastante. Além disso, não foi possível compilar o código fonte do mesmo.

2.2 Minix

Software de uso educacional de sistemas operacionais escrito unicamente em C, tanto o SO quanto as bibliotecas. O Minix [1,2] foi criado depois do Unix e tem código aberto, mas não tem nenhum código advindo do Unix. Foi desenvolvido com fins educacionais, ou seja, com o intuito de alunos poderem aprender o que há dentro de um SO, porque o Unix se tornou comercial e com código fonte não disponível.

O Minix foi desenvolvido inicialmente por Tanenbaum uma década depois do Unix, de uma forma mais estruturada. Tem 12.649 linhas de código, das quais 3000 são comentários. O mesmo suporta multiprogramação, multiusuário e multitarefa. É baseado em uma arquitetura com microkernel e tem ampla documentação.

O Minix é realmente um sistema operacional, não apenas um software de ensino apesar de inicialmente ter sido essa a idéia, logo ele é complexo, pouco prático de instalar, mantê-lo em rede e de em um semestre tornar-se familiar com o mesmo.

2.3 Amoeba

Diferentemente dos demais, o Amoeba [3,4] é um sistema operacional distribuído; ele faz um conjunto de processadores e dispositivos de entrada/saída funcionarem como se fossem um único computador. Os usuários na maioria das vezes não são informados onde seus processos serão executados nem qual tipo de processador será usado, funcionando de forma transparente, como um único sistema de tempo compartilhado. Ele também oferece processamento paralelo onde se pode explorar a existência de diversos processadores gerenciados pelo sistema, dividindo o processamento de um único job por diversas máquinas; logo o Amoeba provê mecanismos para as aplicações distribuídas e paralelas.

O Amoeba foi desenvolvido por Tanenbaum em C e diferentemente dos demais sistemas operacionais distribuídos ele não suporta o conceito de “máquina hospedeira”, ou seja, um comando submetido ao shell pode não rodar na mesma máquina. Ele se baseia num microkernel que trata dos processos, da memória, da comunicação e da entrada/saída. O sistema de arquivo e o restante do sistema operacional rodam como processos do usuário.

2.4 RCOS-java

O RCOS (Ron Chernich's Operating System) é uma ferramenta para ensinar como funciona um sistema operacional intrinsecamente. A versão Java do RCOS [9,10] é baseada no RCOS em C++. Ele tem uma pseudo-máquina (P-Machine), que executa pseudo-código de máquina para um simples e hipotético sistema de computador. O RCOS inclui um compilador C/C++ que gera P-Code (pseudo-código) para ser executado pela P-Machine (pseudo-máquina). O RCOS-java foi desenvolvido em Java usando um bom projeto de código, permitindo aos alunos modificarem-no, fazer experimentos e comparar diversos tipos de estruturas de dados, algoritmos e serviços do sistema operacional proposto.

3 RCOS-java

Neste tópico explanaremos melhor o funcionamento e utilização do RCOS.

Há vários aspectos relacionados à ciência da computação que são difíceis de ensinar e aprender; a disciplina de sistemas operacionais é um exemplo. O RCOS foi desenvolvido baseado nas experiências no ensino de sistemas operacionais nas universidades. Ele foi desenvolvido para ser de fácil entendimento através do uso da linguagem Java com orientação a objeto para ser flexível, extensível e portável, com interface gráfica e de sua utilização através da Internet, pois o mesmo é um applet e pode ser executado através de um navegador, diferentemente dos demais que executam apenas localmente e em modo texto.

RCOS-java é um sistema operacional para ensino com interface gráfica e multi-tarefa sendo executado em um simulador de hardware. Ele suporta uso de semáforos e memória compartilhada (comunicação entre processos), além de gerenciamento de memória, alocação de terminal e escalonamento de processos, porém ainda necessita de gerenciamento de arquivo e disco.

Figura 3 1 Estrutura Interna do Sistema RCOS

A estrutura de desenvolvimento de como o RCOS está implementado está mostrada na Figura 3 1, através do exposto vemos que há a CPU (Unidade Central de Processamento), a RAM (memória de acesso randômico), o Terminal (Unidade Visual de Exposição) e Disco (Disco de Armazenamento Permanente). Estes componentes de hardware são gerenciados pelos seus componentes de software: micro-núcleo, gerenciador de memória, gerenciador de terminal e gerenciador de disco.

A CPU é baseada em pilha simples de uma pseudo-máquina. A pseudo-máquina é um computador hipotético que executa instruções pseudo-código, que estão nos programas .pcd gerados pelo compilador que vêm desenvolvido juntamente com o RCOS. A pseudo-máquina tem 4 registradores: contador do programa, ponteiro de pilha, ponteiro base e registrador de instrução.

O RCOS é um sistema baseado em micro-núcleo, onde a maioria das funcionalidades estão implementadas fora do núcleo. Logo temos os módulos separados para cada um dos gerenciadores.

O RCOS-java necessita de três programas executando para operar que são o servidor do RCOS, o servidor web e o cliente RCOS. Para executar o servidor RCOS executa-se o runme.bat do diretório bin. Execute o soma.bat que é o servidor web de dentro do bin, o mesmo roda na porta padrão 80. Para executar o cliente, que é um applet basta usar um navegador com o jdk1.3 e digitar http://localhost/RCOS.html.

A idéia principal é visualizar todo o ciclo de vida de um programa. Esses programas são gerados pelo compilador que faz parte do projeto do RCOS. O usuário faz programas usando uma linguagem parecida com C/C++, que tem alguns métodos característicos interpretados apenas pelo compilador deste. A saída gerada é o pseudo código que têm a extensão .pcd que são instruções de código para serem executadas pela CPU.

Para instanciar um ou vários programas gerados pelo compilador clica-se no botão “New Process” Figura 3 2 e assim abre-se uma nova janela com os programas .pcd disponíveis. Tem-se a opção de iniciar automaticamente o terminal, que é onde é mostrada a saída do programa como na Figura 3 3.

Figura 3 2 Gerenciador de Programa

O escalonador de processo é mostrado na Figura 3 2 onde temos as filas de processos prontos, processos bloqueados, processos dormindo e a CPU. A fila dos processos dormindo é usada pelos processos que requerem algum recurso a fim de continuar sua execução. A fila dos prontos é usada pelos processos que estão atualmente esperando por tempo da CPU. O processo atual executando é mostrado na CPU. Modificação no tipo do algoritmo usado pode ser feita a qualquer hora pelo usuário, as opções são: FIFO (primeiro a entrar é o primeiro a sair), LIFO (o último a entrar é o primeiro a sair) e Prioridade. O quantum (tempo que o processo fica na CPU) também pode ser alterado bem como a velocidade da execução dos processos.

Figura 3 3 Escalonador de Processos e Terminal

A CPU mostra a visão do p-code (código de máquina) e seu estado atual.

Figura 3 4 Gerenciador da CPU

No gerenciador IPC (Comunicação entre processos) podemos ver a memória atual alocada, o atual semáforo e a memória atual compartilhada. Em tempo real os usuários podem ver a memória que está sendo lida, escrita, alocada e desalocada.

Figura 3 5 Gerenciador entre Processos

Os estudantes podem criar seus próprios programas para executar no RCOS e assim testar conceitos como impasse (deadlock), condição de parada e inanição (starvation).

4 Sistema de Arquivo

Nesta seção serão definidos alguns conceitos para um melhor entendimento da explicação do desenvolvimento do projeto.

Para a maioria dos usuários o sistema de arquivo é a parte mais visível do sistema operacional. O sistema de arquivo consiste de duas partes: arquivo, que armazena dados, e estrutura de diretório qual organiza e têm as informações sobre todos os arquivos do sistema. Abaixo explicaremos os conceitos de arquivo e diretório juntamente com suas características.

4.1 Arquivo

4.1.1 Qual a importância

Todas as aplicações computacionais precisam armazenar e recuperar informações, abaixo lista-se três razões:

1. Para algumas aplicações o espaço de endereçamento virtual é suficiente, porém para outras, tais como as bancárias, ele é muito pequeno.

2. O segundo problema é que certas informações precisam ser lidas depois, porém são perdidas quando o processo termina sua execução. Estas informações não podem ser perdidas quando ocorre uma falha qualquer do hardware, com a conseqüente morte do processo.

3. Outro problema é quando vários processos têm acesso ao mesmo conjunto de informações ao mesmo tempo. Uma boa prática de programação é tornar a informação independente do processo.

A solução, para os problemas acima apontados, é manter a informação armazenada em disco, ou em qualquer outro dispositivo externo de armazenamento, em unidades denominadas arquivos. Os arquivos são gerenciados por uma parte do Sistema Operacional denominado Sistema de Arquivos.

Arquivos podem ser gravados em vários tipos de mídia como: disco magnético, fita magnética, e disco óptico. Para que seja conveniente usar o computador, o sistema operacional proporciona uma visão lógica das informações armazenadas, daí a abstração do que está no disco físico para o usuário é o arquivo.

4.1.2 Atributos dos Arquivos

Quando um processo cria um arquivo, é preciso que tal arquivo receba um nome. Quando tal processo termina sua execução, o arquivo continua a existir, podendo ser acessado por outros processos usando para tanto o nome atribuído ao arquivo.

No MS-DOS, nomes em maiúsculo e minúsculo identificam o mesmo arquivo. Ao contrário do que acontece no Unix. Há ainda a extensão do arquivo que indica a característica do arquivo, isto ajuda um programa que use diferentes tipos de arquivo. No caso de um programa compilador para saber que arquivos compilar e quais linkar por exemplo.

Cada arquivo tem necessariamente um nome como explicado acima e um conjunto de dados. Além disso, o sistema operacional associa a cada arquivo algumas outras informações, como por exemplo a data e a hora em que o arquivo foi criado e seu tamanho. Chamamos estes itens extras de atributos do arquivo. A lista de atributos varia muito de sistema pata sistema. Estes atributos têm vários intuitos, como backup, controle de versão e segurança.

Cada arquivo tem necessariamente um nome e um conjunto de dados. Além disso, o sistema operacional associa a cada arquivo algumas outras informações, como por exemplo a data e a hora em que o arquivo foi criado e seu tamanho. Chamamos estes itens extras de atributos do arquivo. A lista de atributos varia muito de sistema para sistema. Estes atributos têm vários intuitos, como backup, controle de versão e segurança, mas os mais usados consistem dos seguintes:

Figura 4 1 Atributos do Arquivo

4.1.3 Estrutura do Arquivo

Tipos:

- Seqüência de bytes

- Seqüência de registros

- Árvore

Figura 4 2 Estrutura do Arquivo

Tanto o Unix como o MS-DOS, tratam seus arquivos como uma seqüência de bytes, que dá uma flexibilidade enorme ao sistema de arquivos. Os programas de usuário podem colocar o que desejarem nos arquivos e identificá-los da forma que lhes for conveniente. O sistema operacional não ajuda em nada, mas também não atrapalha.

O primeiro passo para se estruturar um arquivo foi através do uso de registros. Neste modelo o arquivo é uma seqüência de registros de tamanho fixo, cada um deles com estrutura interna característica. Logo uma leitura retorna um registro e uma escrita grava um registro.

O terceiro tipo de estrutura de arquivo, na qual o arquivo é composto de uma árvore de registros, não necessariamente do mesmo tamanho, cada um dos quais contendo um campo com chave numa posição fixa do registro. A árvore é ordenada pelo campo da chave, de modo a permitir uma busca rápida pela chave. No exemplo mostrado a ordem alfabética é alfabética.

4.1.4 Tipos de Arquivo

Muitos sistemas operacionais suportam vários tipos de arquivo. Por exemplo, o Unix e o MS-DOS têm;

• Arquivos regulares – são aqueles que contêm a informação do usuário.

• Arquivos de diretório – são arquivos do sistema usados na manutenção do sistema de arquivos.

• Arquivos Especiais de Caracteres – estão diretamente ligados à entrada/saída e são usados para a modelagem de dispositivos seriais de entrada/saída, tais como terminais, impressoras e redes.

• Arquivos Especiais Blocados – são usados para modelar disco.

Em geral, os arquivos regulares são arquivos ASCII, ou binários. De regra os arquivos ASCII são constituídos por linhas de texto e os arquivos binários são simplesmente os arquivos que não são ASCII.

Figura 4 3 Tipo de Arquivo “exe”

Apesar de tecnicamente o arquivo ser uma seqüência de bytes no caso do Unix e MS-DOS, o sistema operacional só executará um arquivo que esteja num dado formato, ou seja, baseado numa estrutura. A estrutura de um arquivo binário executável, no caso do Unix, é formado por 5 partes distintas: cabeçalho, texto, dados, bits de relocação e tabela de símbolos. O cabeçalho começa com um “número mágico”, que identifica o arquivo como um arquivo executável (de forma a prevenir a execução acidental de arquivos fora deste formato). Segue-se um conjunto de 16 bits fornecendo o tamanho de cada uma das partes componentes do arquivo, o endereço de início da execução e alguns bits de flag. Depois do cabeçalho vem o código e os dados do programa, que são carregados na memória e relocados usando os bits de relocação. A tabela de símbolos é usada para depuração.

4.1.5 Operações sobre Arquivos

Para fazer operações sobre os arquivos podemos acessá-los de duas formas: seqüencial, ou seja, na ordem em que os mesmos foram armazenados nos arquivos; ou por acesso randômico ou aleatório, o qual consiste naquele em que os registros e os bytes podem ser lidos em qualquer ordem.

As chamadas de sistema mais comuns relacionadas ao sistema de arquivos são: create, delete, open, close, read, write, append, seek, get atrributes, set attributes, rename. Abaixo explicamos algumas delas.

• Create – dois passos criam o arquivo. Primeiro vê se tem espaço no sistema de arquivo. Segundo, uma nova entrada precisa ser feita no diretório.

• Write – para escrever em um arquivo passa-se o nome do mesmo que é procurado em que diretório se encontra, depois é gravado os dados que pode ser gravado a partir da posição corrente. Se a posição for a final do arquivo, o tamanho do mesmo cresce, senão o arquivo é sobrescrito.

• Open – o propósito desta chamada é permitir que o sistema busque os atributos e a lista dos endereços em disco correspondentes a este arquivo, carregando estas informações na memória principal, de maneira a tornar mais rápido os acessos subseqüentes a este arquivo.

• Read – para ler o arquivo passamos o nome do mesmo, daí procuramos nos diretórios por uma entrada para esse arquivo. Usualmente os bytes são lidos a partir da posição atual do ponteiro, e o processo que chamou deve indicar a quantidade de informação a ser lida.

• Close – quando não houver mais acesso a determinados arquivos, seus atributos e endereços de disco não precisam mais ser mantidos na memória, logo o arquivo pode ser fechado.

• Delete – quando um arquivo não for mais necessário ele deve ser removido Procuramos pelo nome do arquivo a ser removido, achando uma entrada de diretório para ele no diretório podemos apagá-lo e a entrada do mesmo. Há sistemas que apagam arquivos não usados por n dias.

4.1.6 Arquivos mapeados na Memória

Se cada vez que precisarmos utilizar um arquivo tivermos que acessa-lo em disco, isso seria extremamente custoso e ineficiente, principalmente quando comparamos tal operação com a de acesso à memória principal. Logo a mlehor solução é mapear arquivos na memória (no espaço de endereçamento do processo que estiver rodando).

O mapeamento de arquivo funciona melhor em um sistema que suporte segmentação. Como mostrado na Figura 4 4, em tais sistemas, cada arquivo pode ser mapeado para um segmento próprio, de forma que o byte k do arquivo corresponda ao byte k do segmento. O processo deve ser segmentado antes de mapear seus arquivos no seu espaço de endereçamento. Após isso o processo mapeia um arquivo existente abc em um segmento e cria um novo segmento para o arquivo xyz. Depois disso os arquivos são removidos do espaço de endereçamento, e então o arquivo de saída passa a existir como se ele tivesse sido criado de maneira convencional de disco para o disco e não sendo copiado em memória antes de ir para o disco de fato.

Figura 4 4 Arquivos mapeados em Memória

Apesar do mapeamento de processo eliminar a necessidade de entrada/saída, tornando a programação mais simples, ela tem alguns problemas:

• É difícil para o sistema saber o tamanho exato do arquivo de saída xyz. É fácil informar o número da página de mais alta ordem que foi escrita, mas não há como saber quantos bytes desta página foram escritos.

• Ocorre problema se o arquivo for mapeado por um processo e aberto por outro para fazer leitura. O sistema deve garantir que estes dois processos não estão tratando com duas versões inconsistentes do arquivo.

• O arquivo pode ser maior do que o segmento, ou mesmo maior do que todo o espaço de endereçamento virtual. A solução seria fazer o mapeamento de pedaços do arquivo e não o arquivo inteiro.

4.2 Diretório

Para tratar dos vários arquivos existentes no disco, o sistema operacional faz uso do conceito de diretório, que em muitos casos é apenas um arquivo.

Figura 4 5 Organização Típica de Diretório

Normalmente cada disco do sistema têm pelo menos uma partição onde os arquivos e diretório residem. No diretório existem entradas de diretório que correspondem a cada arquivo ou sub-diretório do mesmo. A Figura 4 5 mostra uma organização típica de diretório, na qual pode haver um disco dividido em 2 partições ou dois discos formando uma mesma partição.

O diretório pode ser organizado de várias maneiras, mas temos que ser capazes de realizar algumas operações como: create, delete, opendir, closedir, readdir, rename, link, unlink.

• Create – cria um diretório. Ele é vazio, contendo apenas o ponto e o pontoponto

• Delete – apaga um diretório, somente um diretório vazio pode ser removido. O diretório contendo apenas o ponto e o pontoponto, apesar de ser considerado vazio, geralmente não pode se apagado

• Opendir – antes de o diretório ser lido ele precisa ser aberto

• Closedir – após um diretório ter sido lido ele precisa ser fechado para liberar espaço na tabela de memória

• ReadDir – retorna a próxima entrada em um diretório aberto

• Rename – Os diretórios podem mudar de nome assim como seus arquivos

• Link – permite que um arquivo apareça em mais de um diretório

• UnLink- remove a entrada de um diretório

4.2.1 Organização do Sistema

Nesta seção serão descritas algumas formas de esquemas lógicos de estrutura de diretório.

Um diretório contém um conjunto de entradas, uma por arquivo. Uma das possibilidades é cada entrada conter o nome do arquivo, seus atributos e os endereços no disco onde ele está armazenado, ou o nome do arquivo e um ponteiro para outra estrutura de dados onde se podem encontrar os atributos do arquivo e seus endereços no disco.

Quando um arquivo é aberto os atributos e seus endereços são colocados em uma tabela na memória. Todas as referências subseqüentes a tal arquivo usam as informações da memória principal.

Se temos arquivos diferentes como nomes iguais, eles não podem coexistir num mesmo diretório logo surgiu a idéia de hierarquia genérica, por exemplo, através de uma árvore de diretórios. Assim podemos ter tantos diretórios quantos necessários.

A forma mais comum é aquela em que tem-se um único nível, ou seja, há apenas um diretório simples. Todos os arquivos estão num mesmo diretório, o qual é fácil de dar suporte e entender. Esta forma tem limitações principalmente quando o número arquivos e usuários crescem, pois já que os arquivos estão no mesmo diretório, eles precisam ter nomes diferentes.

A maior desvantagem do diretório de um único nível é a confusão dos nomes de arquivos criados pelos diferentes usuários. A solução padrão é criar um diretório separado para cada usuário. Nessa arquitetura cada usuário tem seu próprio diretório.

Figura 4 6 Sistema de Arquivo Hierárquico

A terceira opção é o Sistema de Diretório Hierárquico onde resolvemos os problemas dos esquemas anteriores. Quando o sistema é organizado como uma árvore de diretório, é necessária uma regra para a formação dos nomes dos arquivos. Há 2 métodos muito conhecidos. Em um a cada arquivo é dado um nome de caminho absoluto composto do caminho do diretório raiz até o arquivo. O segundo método de formação de nome é o nome de arquivo relativo, e é usado em conjunto com o conceito de diretório de trabalho ou diretório corrente, ou seja, sabendo o diretório corrente é mais fácil digitar o nome do arquivo que todo o caminho absoluto.

4.3 Implementação do Sistema de Arquivo

Nesta seção serão abordadas as implementações dos arquivos e do diretório com base nas definições feitas sobre ambos anteriormente.

4.3.1 Implementação de Arquivos

O ponto-chave na implementação do armazenamento de arquivos é associar blocos de disco a arquivos. Há vários métodos tais como: Alocação Contígua, Alocação com Lista Ligada, Alocação com Lista Ligada Usando um Índice e Nós-i.

4.3.2 Tipos de implementação de arquivo

Alocação Contígua

O mais simples de todos os esquemas de alocação, onde cada arquivo é armazenado no disco como um bloco contínuo de dados. Há 2 vantagens neste esquema: é simples de implementar pois o controle de onde está o arquivo reduz-se a guardar o endereço em disco de seu primeiro bloco, e a performance é ótima porque todo o arquivo pode ser lido do disco em uma única operação.

Porém há 2 desvantagens: só pode ser usado se o tamanho do arquivo for conhecido no momento de sua criação, sem isso o sistema operacional não pode saber quanto espaço em disco deve ser reservado. Outro problema é a fragmentação do disco que torna-se cara devido a esta política de alocação.

Alocação com Lista Ligada

Neste método mantém-se o espaço alocado ao arquivo como uma lista ligada de blocos. A primeira palavra de cada bloco é usada como um ponteiro para o próximo bloco. O restante do bloco é usado para armazenamento das informações pertencentes ao arquivo. As vantagens são: ao contrário da alocação contígua, qualquer bloco do disco pode ser usado. Não se perde espaço por fragmentação do disco. Além disso, a entrada do diretório só precisa armazenar o endereço em disco do primeiro bloco do arquivo. O restante do arquivo pode ser encontrado começando no ponto indicado no diretório.

As desvantagens deste método são: o acesso randômico é lento e mais difícil de implementar do que o seqüencial. E, além, disso a quantidade de informações armazenadas em um bloco não é mais uma potência de dois, em função da necessidade de se armazenar o ponteiro no bloco.

Alocação com Lista Ligada Usando um Índice

Ambas as desvantagens apontadas para a alocação com listas ligadas podem ser eliminadas tirando-se o ponteiro de cada um dos blocos e colocando-os em uma tabela ou índice na memória.

Usando esta organização, todo bloco fica disponível para armazenamento da informação. Apesar do acesso ser randômico, é mais simples de ser implementado. Apesar de a cadeia ter de ser seguida para encontrar um deslocamento dentro do arquivo, a cadeia está toda na memória e não há necessidade de acesso a disco. Basta que a entrada do diretório contenha o número do bloco inicial. O MS-DOS usa este método para alocação de espaço em disco.

A maior desvantagem é que toda a tabela deve estar na memória durante todo o tempo.

Nós-i

Este último método para controlar a correspondência entre blocos no disco e arquivos consiste em associar a cada arquivo de uma pequena tabela denominada nó-i(nó índice), que lista os atributos e os endereços em disco dos blocos do arquivo.

Os primeiros endereços de disco são armazenados no próprio nó-i, de maneira que, para arquivos pequenos, toda a informação é encontrada diretamente no nó, sendo a informação transferida do disco para a memória quando o arquivo for aberto. Em arquivos maiores, um dos endereços no nó-i é o endereço de um bloco do disco chamado bloco indireto simples . Tal bloco contém endereços adicionais no disco relativos ao arquivo em questão. Caso o arquivo seja maior usa-se o bloco indireto duplo que aponta para 2 blocos simples, ou o bloco indireto triplo que aponta para 3 blocos simples os quais apontam para mais dois blocos simples cada um deles. O Unix segue este esquema.

4.4 Implementação de Diretório

Antes do arquivo ser lido ele precisa ser aberto. Ao abrir um arquivo, o sistema operacional usa o nome fornecido pelo usuário para procurar sua entrada no diretório. Tal entrada fornece as informações necessárias a encontrar os blocos deste arquivo. Dependendo do sistema, esta informação pode ser simplesmente um endereço do disco válido para todo o arquivo (alocação contígua), o número do primeiro bloco do arquivo (alocação com listas ligadas), ou mesmo o número do nó-i relativo ao arquivo. Nestes casos, a principal função do diretório é mapear o nome ASCII do arquivo na informação necessária à localização do dado.

Os atributos podem ser armazenados na entrada do diretório ou outra possibilidade é armazenar nos próprios nós nos sistemas que usam nó-i.

4.4.1 Tipos de implementação de diretório

Diretórios no CP/M

Só existe um diretório e tudo o que o sistema operacional deve fazer é procurar o nome do arquivo no diretório e obter os números dos blocos do disco bem como os atributos correspondentes a este arquivo.

Diretórios no MS-DOS

O MS-DOS e alguns outros sistemas usam árvores de diretório na implementação de seus diretórios. Uma entrada para diretório no MS-DOS possui 32 bytes e tem os seguintes campos: nome do arquivo, extensão, atributos, reservado, hora, data, número do primeiro bloco. Este número é usado como índice para uma tabela do tipo alocação com lista ligada. Seguindo a cadeia todos os blocos podem ser encontrados.

No MS-DOS diretórios podem conter outros diretórios, levando a uma estrutura hierárquica para o sistema de arquivo.

Diretório no Unix

A estrutura adotada pelo Unix é bastante simples. Cada entrada contém simplesmente um nome de arquivo, e o número do seu nó-i. Todas as informações sobre tipo, tamanho, tempos, proprietários e blocos de disco estão contidas no nó-i.

4.4.2 Algoritmo de busca no diretório

O algoritmo para se abrir um arquivo é basicamente o mesmo para qualquer sistema de diretório hierárquico. Temos que localizar os blocos do disco correspondente ao nome do arquivo fornecido na chamada.

Ex de caminho: /usr/ast/mbox

Em primeiro lugar ele localiza o diretório-raiz. No Unix, seu nó-i está localizado num endereço fixo do disco.

A seguir ele procura pelo primeiro componente do caminho, usr, no diretório-raiz, para encontrar o número do seu nó-i. Localizar o nó-i a partir do seu número é muito simples, uma vez que cada um deles tem uma localização fixa no disco. A partir deste nó-i, o sistema localiza o diretório para /usr e busca nele as informações sobre o próximo componente ast. Quando a entrada correspondente a ast for encontrada, o sistema obtém o nó-i para o diretório /usr/ast. Deste nó-i ele pode encontrar o diretório procurado e acessar mbox. O nó-i deste arquivo é então transferido para a memória e mantido lá até que o arquivo seja fechado.

Nomes relativos são pesquisados da mesma forma que os absolutos, só que a busca é iniciada do diretório de trabalho, em vez de começar do diretório-raiz.Cada diretório tem entrada para “.” e “..” que são colocados lá quando é criado o diretório. A entrada tem o mesmo número do nó-i do diretório corrente, e a entrada tem o número do nó-i do seu diretório-pai, respectivamente.

5 MS-DOS

O desenvolvimento desse projeto foi baseado no sistema de arquivo do MS-DOS, abaixo tem-se a história do MS-DOS, em que ele foi baseado e sua evolução em relação aos sistemas da época e em relação ao sistema de arquivo.

MS-DOS é um exemplo de sistema operacional para máquinas com um único processador. O mesmo só roda em arquiteturas baseadas nos processadores Intel 8088 e seus sucessores. Apesar disso, o MS-DOS é de longe, o sistema operacional mais utilizado de todos os tempos, tendo alcançado a respeitável marca de 50 milhões de cópias vendidas. Esta seção foi baseada no livro Modern Operating Systems de Tanembaum [12]

5.1 História do MS-DOS

O primeiro computador pessoal foi o Altair, produzido em 1975 por uma companhia chamada MITS, de Albuquerque, Novo México, EUA. Ele era baseado no microprocessador 8080, de oito bits, fabricado pela Intel, e tinha 256 bytes de memória. O Altair não tinha teclado, nem vídeo, e muito menos disco ou fita, mas seu preço muito baixo, em torno de 400 dólares, transformou-o num culto para os eletrônicos amadores, que cresceram a montando kits de rádios e televisões vendidos em bancas de jornal. Um jovem chamado Bill Gates escreveu uma versão do BASIC para o Altair, que obteve um sucesso modesto junto aos usuários do microcomputador. Mais tarde este programa veio a fazer de Gates um bilionário.

Em poucos anos, muitas empresas começaram a produzir microcomputadores baseados no chip 8080. Em quase todas estas máquinas, rodava o sistema operacional chamado CP/M, produzido por uma pequena empresa da Califórnia, a Digital Research. Todos os computadores pessoais (chamados de microcomputadores) projetados de 1975 até o início da década de 80 nada mais eram que brinquedos comprados e utilizados fundamentalmente pelas pessoas que tinham a eletrônica como hobby.

5.1.1 O PC IBM

No início dos anos 80, a IBM, que então dominava a indústria de computadores, decidiu entrar no negócio da computação pessoal. No entanto, quando tomou uma decisão sobre o assunto, já era tarde para desenvolver um projeto próprio. Por conta disso, seus executivos decidiram fazer algo que não era usual para a cautelosa e burocrática IBM. Enviaram um de seus agentes, Philip Estridge, para Boca Raton, na Flórida. Partiram de Westchester, Nova Iorque, com uma mala cheia de dinheiro, com a recomendação de não voltar a Nova Iorque sem um projeto de computador pessoal no bolso.

Estridge percebeu logo que a única maneira de se produzir rapidamente um computador pessoal era utilizando componentes-padrão, em vez dos projetados internamente, pela própria IBM, como ela sempre fazia. Nesta época, a Intel já tinha produzido dois sucessores para o 8080, o 8086, de 16 bits, e o 8088, uma versão do 8086, com um barramento de oito bits. Estridge escolheu o 8088, pois os chips que davam suporte a este processador eram muito mais baratos que os do 8086, Esta decisão baseou-se no fato de o preço de venda da máquina ser o ponto de maior importância de todo o projeto.

Além de não ter interesse em construir ela própria os chips para equipar seu computador pessoal, a IBM estava muito menos interessada em escrever software para ele. Seus executivos sabiam que o BASIC era muito popular entre os usuários de computadores pessoais, de modo que eles foram consultar Bill Gates, que nesta época já tinha fundado uma nova empresa, chamada Microsoft, a fim de licenciar o interpretador BASIC para ser usado no IBM-PC, Pediram também que Gates desenvolvesse um sistema operacional para a nova máquina.

A Microsoft, porém, estava dedicada ao projeto de vender o UNIX, sob licença do Bell Labs (AT&T). Ocorre que o UNIX, originário do mundo dos minicomputadores, precisava de 100k de memória só para o sistema operacional, e também de um disco rígido. A máquina da IBM tinha um total de 64k de memória, e não era equipada com disco rígido. Em função disso, Gates sugeriu que a IBM usasse o CP/M-86, desenvolvido pela Digital Research. A IBM consultou a Digital Research, que respondeu que o desenvolvimento do CP/M-86 estava atrasado em relação ao cronograma original, e a IBM não podia esperar.

Mais uma vez, a Microsoft foi procurada. Desta vez consultada sobre a possibilidade de escrever um sistema operacional com as mesmas características do CP/M-86. Os projetos de Gates o impediram de assumir a empreitada e realizá-la no prazo exigido pela IBM. Ele, porém, sabia que uma empresa vizinha da Microsoft, a Seatle Computer Products, havia desenvolvido um sistema operacional CP/M-like, denominado 86-DOS, para testar as placas de memória que ela produzia e vendia. A Microsoft então comprou o 86-DOS, e em abril de 1981, contratou seu projetista, Tim Paterson, para torná-lo ainda menor. Eles mudaram o nome do sistema para MS-DOS (MicroSoft – Disk Operating System), entregando-o à IBM dentro do prazo combinado. Quando o IBM PC foi anunciado em agosto de 1981, o MS-DOS estava junto com ele.

Na versão da IBM e de muitos outros fabricantes, a maior virtude do MS-DOS era a de permitir que os softwares desenvolvidos para CP/M, que rodavam no processador 8080 (o 8088 era compatível com o 8080, e podia rodar a maioria de seus programas com pouquíssimas modificações), rodassem também sob o MS-DOS. Ninguém poderia imaginar que 10 anos depois este pequeno sistema, que surgiu no mercado quase que por acidente, pudesse estar controlando o funcionamento de 50 milhões ou mais de computadores espalhados pelo mundo inteiro.

Além do mais, ninguém, nem mesmo a IBM, tinha a menor idéia do sucesso que o IBM PC iria alcançar. A IBM imaginava inicialmente que ele seria usado para jogos, Basta ver a freqüência de 4,77MHz do seu clock foi escolhida em função da compatibilidade com a usada nos sistemas de televisão americanos, de maneira a permitir que as pessoas usassem seus próprios aparelhos de TV como vídeo, em vez de monitores específicos. O PC também vinha equipado com hardware para controlar aparelhos de gravação/reprodução de fitas cassete, que poderiam ser usadas como meio de armazenamento, e joysticks. Nenhum destes dois dispositivos teve muito uso, em virtude da inexistência de softwares para eles.

Provavelmente a melhor coisa que a IBM fez foi tornar o PC um sistema aberto. O projeto completo, inclusive as listagens da ROM e os diagramas elétricos foram descritos em detalhes em um livro que estava disponível em todos os pontos de venda dos PCs. Isto fez com que fosse possível usar no PC tanto produtos de hardware quanto de software, produzidos por terceiros, a exemplo do que foi feito para os milhares de fabricantes.

De fato, com os diagramas de circuitos disponíveis, e a máquina composta exclusivamente para os componentes não dedicados, que podiam ser comprados em qualquer loja de eletrônica, muitas empresas passaram a construir e a vender cópias do PC, conhecidas como clones, entretanto em competição direta com a própria IBM. Foi devido a esta enorme carga de energia e criatividade que o PC teve tanto sucesso, e a reboque dele, o MS-DOS.

5.1.2 MS-DOS Versão 1.0

O sistema operacional era constituído por três programas: o ibmbio.com, que tratava do disco e do sistema de entrada/saída voltado a caracter; o ibmdos.com, que é o gerenciador de arquivos e do disco, e o comannd.com.

A primeira versão do MS-DOS, a exemplo do CP/M, suportava somente um único diretório, ou seja, não suportava sub-diretórios. Ao digitar o comando dir, para listar todos os arquivos do diretório corrente, o que você realmente via era a listagem de todos os arquivos do sistema.

Apesar da versão 1.0 do MS-DOS ter sido compatível com o CP/M, ela era melhor que este. O MS-DOS trazia informações sobre o arquivo como o tamanho exato do mesmo, tinha um algoritmo melhor para alocação de disco e era muito mais rápido. A versão 1.1 foi liberada pela Microsoft em 1982 e também consertou alguns bugs.

5.1.3 MS-DOS Versão 2.0

A IBM em março de 1983 lançou o PC/XT, seu primeiro computador pessoal equipado com disco rígido junto com a nova versão 2.0 do MS-DOS. O sistema de arquivo do MS-DOS foi quase todo inspirado no do Unix. O MS-DOS no sistema de arquivo usa o conceito de FAT e o Unix usa o conceito de I-nodes. As chamadas open, read, write e close estavam presentes na versão 2.0, exatamente com a mesma estrutura do Unix.

No processo de adicionar novas características do Unix, o MS-DOS cresceu para 20.000 linhas de código de montagem. Ele também tirou do mercado o CP/M-86, que finalmente tinha tido seu desenvolvimento terminado, e estabeleceu-se como o sistema operacional dominante para os PCs. Por ter introduzido o disco rígido nos PCs tornou-se possível rodar aplicações razoavelmente grandes, fazendo com que eles deixassem de ser computadores pessoais para se tornarem também máquinas comerciais. Empresas de pequeno, médio e grande portes começaram a adquirir PCs.

Nessa época o MS-DOS era mantido por somente quatro pessoas na Microsoft. Com o crescimento da demanda mundial pelo sistema, a Microsoft contratou novos programadores e lançou a versão 2.05, que suportava horários, datas, moedas, e símbolos decimais, usados em muitos países do mundo.

5.1.4 MS-DOS Versão 3.0

A IBM lançou o PC/AT em agosto de 1984, seu primeiro computador pessoal baseado no chip 286. Nesta época também surgiram discos de 10MB e o conceito de disco em RAM, através da qual uma parte da memória era usada como se fosse um disco muito rápido.

Quase na mesma época do lançamento do MS-DOS 3.3, a IBM e a Microsoft liberaram um sistema operacional completamente novo, denominado OS/2. Na visão das duas empresas, o OS/2 iria substituir o MS-DOS. Isto nunca aconteceu. O OS/2 foi liberado com muito atraso, e pior que isto, incompleto. Apesar dele ter muitas vantagens sobre o MS-DOS, tal como usar toda a memória disponível, rodar em modo protegido, suportar multiprogramação de uma forma elegante, o mercado não se interessou muito pelo novo sistema. Em 1991, a Microsoft anunciou que estava abandonando completamente o OS/2, o que irritou profundamente a IBM, a ponto de romper sua aliança com a Microsoft, e assinar um acordo com a Apple Computer para fornecimento de seus softwares.

5.1.5 MS-DOS Versão 4.0

Depois da IBM ter se convencido que o OS/2 não iria ser aceito pelos usuários, ela surpreendeu lançando o MS-DOS versão 4.0, o qual a Microsoft também produziu. Para obter a versão 4.0 a mesma usou o método de engenharia reversa, distribuindo-o através dos fabricantes de clones do PC. Tanto a IBM quanto a Microsoft se convenceram de que o MS-DOS não iria desaparecer pois em lugar de contribuir para exterminar o MS-DOS, como fora a intenção revelada de ambas as empresas, elas estavam melhorando o sistema que não deveria continuar.

5.1.6 MS-DOS Versão 5.0

A versão 5.0 foi anunciada em abril de 1991. Nesta versão foi considerada seriamente a questão da memória estendida. Apesar de ainda haver a restrição na memória estendida de apenas poder-se usar 640K, esta versão é capaz de manter por mais tempo a maior parte de seu próprio código na memória estendida, logo fica disponível para os programas de usuário em torno de 600K.

Esta nova versão passou a ser vendido em lojas e não mais apenas aos fabricantes de computador.

A versão 5.0 do MS-DOS já era obsoleta quando foi anunciada. A IBM e a Microsoft já sabiam disso por isso investiram muito milhões de dólares no OS/2. Infelizmente o mercado reagiu mal ao OS/2. Quando ficou claro que o OS/2 não decolaria a Microsoft mudou sua estratégia e desenvolveu o Windows, com interface gráfica e uso de mouse, que rodava em cima do MS-DOS. O lado positivo disto é o fato de ele ter acumulado uma quantidade imensa de pacotes de aplicativos de alta qualidade.

5.2 O Sistema de Arquivo

O sistema de arquivo original do MS-DOS foi baseado no CP/M. A princípio só existia um diretório. A partir da versão 2.0 foi adotado o modelo hierárquico do sistema de arquivo.

A partir desta nova versão o diretório raiz podia ter subdiretórios e estes tenham novos sub-diretórios. O sistema de arquivo usa os nomes “.” e “..” para indicar diretório corrente e diretório-pai respectivamente.

Os nomes dos arquivos tem até 8 caracteres, seguidos de uma extensão de até 3 caracteres. Os nomes são formados por qualquer seqüência legal de caracteres. O separador de diretório no mesmo é o “\”. Outra coisa interessante é que os arquivos PROFESSOR, Professor, professor indicam um único arquivo, ou seja, ele desconsidera maiúsculas e minúsculas.

Cada arquivo no MS-DOS tem atributos. Eles são quatro:

1. Readonly – o arquivo não pode ser modificado

2. Archive – o arquivo modificado desde o último arquivamento

3. System – arquivo de sistema que não pode ser apagado pelo comando del

4. Hidden – arquivo não listado pelo comando dir

O MS-DOS suporta vários discos, então quando o usuário quiser remover um arquivo ele deve especificar o dispositivo como exemplo “a:” para unidade de disquete e “c:” para disco rígido por exemplo.

O disquete e o disco rígido são organizados de forma diferente e vamos nos concentrar no segundo tipo. Todos os discos rígidos têm a mesma estrutura, mostrada na Figura 5 1. O setor de boot tem dados críticos para o sistema de arquivo, além de código para inicializar o sistema. Depois vêm as tabelas que controlam todo o espaço do disco. Elas são seguidas pelo diretório-raiz e por todo o resto.

Figura 5 1 Organização do disco no MS-DOS

O setor de boot sempre começa com uma instrução de desvio incondicional, que salta pelas informações do setor e vai para o início do código, sem se preocupar com a estrutura interna do disco. Depois vem uma lista de informações como número de bytes do setor, o número de setores por bloco, o número de arquivos das tabelas de alocação, o tamanho do diretório raiz, o tamanho do dispositivo e outros dados.

Após estes parâmetros vem o código de boot, e ao final a tabela de partição. Ela contém o começo e o termino de cada uma das partições do disco, até um máximo de quatro partições, cada uma podendo conter um sistema de arquivo diferente. Alguma das partições deve ser marcada como ativa para quando o boot do disco for acionado saber qual sistema inicializar.

Após o setor de boot encontra-se a FAT (Tabela de Alocação de Arquivos – File Allocation Table), a qual controla todos os espaços do dispositivo. Para ter-se confiabilidade esta tabela pode ser duplicada, de modo ao sistema tornar-se inacessível caso a FAT principal não possa ser lida por qualquer motivo.

A FAT contém uma entrada para cada bloco do disco. O tamanho do bloco é obtido do setor de boot. O formato conceitual da FAT é mostrado na Figura 5 2. O seu formato real retrocede às raízes do MS-DOS, baseado no CP/M. Há uma correspondência um-para-um entre as entradas da FAT e os blocos do disco, exceto pelas duas primeiras entradas, as quais possuem o código da classe do disco. No exemplo vemos que através da FAT descobrimos quais blocos ocupam cada arquivo.

A entrada do diretório de cada arquivo possui o número do primeiro bloco que o mesmo ocupa, então a partir disso e com o auxílio da FAT temos que todo o arquivo é encontrado. Os blocos livres na FAT são marcados com um símbolo especial. Quando o arquivo cresce o MS-DOS procura por uma entrada livre na FAT, e aloca este para o arquivo. E os blocos que estão com falha são marcados na FAT com outro símbolo significando isto.

Figura 5 2 FAT - Tabela de Alocação de Arquivo

Exemplo de passos seguidos pelo MS-DOS para a chamada OPEN:

O MS-DOS vai na tabela de descritores de arquivo, mantida como array de 20 bytes. Cada byte armazena um índice de 1 byte para a tabela de arquivos do sistema. Se for localizado um descritor de arquivo livre, busca-se uma posição livre na tabela de arquivo do sistema. Caso as duas operações tenham sucesso o caminho é analisado, se começar com \, o caminho é absoluto e a busca começa do diretório-raiz, senão o caminho é relativo, e a busca começa do diretório de trabalho. A entrada do diretório é copiada na tabela de arquivos do sistema, que tem uma entrada para cada arquivo aberto. Depois, o descritor de arquivo retorna ao processo que chamou OPE, e termina a execução da chamada.

Figura 5 3 Entrada de Diretório no MS-DOS

Cada entrada de diretório no MS-DOS tem 32 bytes para cada arquivo ou diretório contido nele, conforme Figura 5 3. Os primeiros 11 caracteres guardam o nome do arquivo e sua extensão, logo depois tem-se o byte de atributos, contendo os seguintes bits:

A - Igual a 1 quando o arquivo é modificado.

D - Igual a 1 para indicar que a entrada é referente a um diretório.

V - Igual a 1 para indicar que esta entrada é para o nome de volume.

S - Igual a 1 para arquivos de sistema, que não podem ser apagados.

H - Igual a 1 para indicar arquivos escondidos, ou seja, não listados pelo dir.

R - Igual a 1 para indicar arquivos que não podem ser escritos.

A data e a hora da última modificação feita no arquivo são armazenadas nos próximos campos. Os campos seguintes guardam número do primeiro bloco do arquivo e seu tamanho.

6 O Sistema de Arquivo Proposto para o RCOS

Sabemos a importância de se ensinar de forma mais interativa a disciplina de sistemas operacionais devido a deficiência na aprendizagem de alguns conceitos complexo e/ou abstratos. O RCOS-java é um software de código aberto desenvolvido com o intuito de fazer os alunos aprenderem melhor a disciplina. O projeto desenvolvido foi uma extensão do RCOS no módulo de sistema de arquivo que é a parte mais visível do sistema operacional na visão de um usuário comum e de grande importância na disciplina.

Esta seção expõe: o desenvolvimento do projeto, o diagrama de classe para mostrar como foi estruturado, detalhes das estruturas principais do mesmo, a interface, as regras de negócio executadas, como as informações são guardadas de forma consistente, as decisões de projeto, problemas encontrados e um guia rápido de como utilizar o sistema.

6.1 Desenvolvimento do Sistema de Arquivo do RCOS

No projeto desenvolvemos uma simulação do sistema de arquivo do sistema operacional MS-DOS, mostrando-o graficamente. Acima há algumas definições sobre: arquivo, a plataforma DOS e o sistema de arquivo do DOS. A proposta é mostrar graficamente como funcionam as operações básicas de um sistema de arquivo como ler, escrever e remover. As várias partes do sistema de arquivo estão de forma simplificada, pois o propósito é educacional.

Devido ao código estar comentado e bem estruturado usando a linguagem java e os conceitos de orientação a objeto, os alunos podem fazer melhorias no mesmo de forma prática no módulo de sistema de arquivo. O RCOS foi também desenvolvido em Java.

6.2 Diagrama de Classe

O projeto está estruturado em três módulos principais, o diretório, a FAT e o Disco. Assim como no MSDOS, desenvolvemos a estrutura hierárquica de diretório que não é trivial.

Na Figura 3 1 mostramos que a classe MSDOSFileSystem e que a mesma tem instâncias de cada uma das classes principais que são: MSDOSFat, Diretory e Disk.

Na classe Diretory usamos uma Hashtable que contém as entradas de diretório, que são representadas pela classe básica MSDOSFile. A FAT foi implementada por uma Hashtable (coleção de entradas da FAT) que são equivalentes a classe básica MSDOSFATEntry. O Disk foi implementado por um Vector de blocos que corresponde a classe básica Block.

A classe MSDOSFileSystem é uma camada onde são executas as regras de negócio do projeto.

As classes principais da interface são a FileSystemFrame e FileSystemAnimator. Através das mesmas tem-se o controle do que é exibido ao usuário e do controle dos eventos executados pelo mesmo.

A classe RCOS é o applet que é chamado pelo arquivo RCOS.html quando o arquivo é colocado para executar. Ele inicializa cada módulo do sistema dentre eles a interface e a fachada do sistema de arquivo, que é a classe FileSystemManager.

Figura 6 1 Diagrama de Classe do Sistema de Arquivo do RCOS

6.3 Estruturas Principais

Nesta seção serão mostradas em detalhes de implementação dos módulos principais do projeto.

6.3.1 Diretório

O sistema de arquivo do RCOS permite que o diretório raiz tenha subdiretórios, e que estes tenham mais subdiretórios, formando um sistema de arquivo em profundidade infinita, esta é o que corresponde a termos uma estrutura hierárquica de diretório. A classe Diretório foi implementada tendo-se várias entradas para cada sub-diretório ou arquivo contido nele, os quais são inseridos numa hashtable. Cada entrada da hash corresponde a um arquivo ou sub-diretório com alguns campos básicos, os quais foram agrupados na classe MSDOSFile. A chave da hash correspondente a cada MSDOSFile é um objeto da classe que tem o nome do arquivo e um boleano para saber se o mesmo é um arquivo ou diretório. É através dessa chave que fazemos as buscas para saber se um sub-diretório ou arquivo pertence ao diretório, e o mesmo tem esse dois campos para permitir que arquivo e sub-diretório que tenham o mesmo nome possam coexistir num mesmo diretório.

A classe MSDOSFile mostrada graficamente na Figura 6 2 corresponde a uma das entradas do diretório que tem como atributos: o nome do arquivo; sua extensão; byte de atributos significando: se é arquivo, se é diretório, se a entrada é para nome de volume, se é arquivo de sistema, se é arquivo escondido, se arquivo pode ser escrito; a data e hora da criação; o primeiro bloco da FAT e a quantidade de blocos ocupado por esse arquivo ou diretório.

Byte de atributos (mostrado na Figura 6 2), o padrão do bit é 0 (zero).

A- Igual a 1 quando tem-se um arquivo.

D- Igual a 1 quando tem-se um diretório.

V- Igual a 1 quando tem-se nome de volume.

S- Igual a 1 para arquivos de sistema que não podem ser apagados.

H- Igual a 1 para indicar arquivos escondidos, ou seja, não listados pelo dir.

R- Igual a 1 para indicar arquivos que não podem ser escritos.

Figura 6 2 Entrada de Diretório do RCOS

Através da classe Diretório adiciona-se novas entradas até o limite de 4k, que corresponde ao tamanho de um bloco. Nela pode-se fazer operações como adicionar, ler e remover arquivo ou sub-diretório (um por vez). O método dir (ler diretório) monta todos os arquivos e sub-diretórios desse diretório concatenando seus atributos com nome, extensão, data de criação, quantidade de blocos ocupados.

Há ainda o método que corresponde aos blocos que devem ser pintados: no caso do comando dir ser executado, os primeiros blocos de cada arquivo ou sub-diretório desse diretório são pintados; nos casos de arquivo ou diretório os blocos correspondentes aos mesmos são pintados. Em caso de leitura, escrita, remoção e não alocados correspondem respectivamente à azul, vermelho, verde e cinza.

Uma limitação do projeto, é que apesar do arquivo ocupar mais de um bloco caso o mesmo seja grande (maior que 4K), o diretório que ocupa blocos igualmente ao arquivo não pode ultrapassar 4k, ou seja o mesmo não é expandido caso o tamanho dele cresça. Esta foi uma decisão de projeto para simplificar o problema devido a falta de tempo hábil.

6.3.2 FAT

O formato da FAT desenvolvida no projeto é mostrado na Figura 6 3. Existe uma correspondência de um-para-um entre as entradas da FAT e os blocos do disco. No exemplo abaixo temos dois arquivos A e B. O arquivo A começa no bloco 4. A entrada na FAT correspondente ao bloco 4 contém o valor 7, significando que o segundo bloco do arquivo é o bloco 7. A entrada 7 da FAT contém 2, significando que o bloco 2 é o terceiro bloco do arquivo. Seguindo essa lógica chegamos a entrada 12 da FAT tem o código especial armazenado nela, indicando o fim do arquivo através do código -2.

A entrada do diretório de cada arquivo possui a informação do número do primeiro bloco de tal arquivo. Então dado o número do primeiro bloco do arquivo, é possível localizar todos os blocos correspondendo a todo o conteúdo do arquivo, seguindo a cadeia da FAT que fornece o restante das informações. Assim todos os blocos do disco correspondentes a qualquer arquivo ou diretório podem ser acessados.

Essa tabela de alocação desenvolvida usa a classe Hashtable de Java, na qual a chave de entrada da mesma é o índice da FAT, a classe correspondente a essa estrutura é a MSDOSFAT.

Figura 6 3 Tabela de Alocação de Arquivo do RCOS

Os blocos livres e de fim de arquivo na FAT possuem códigos diferentes, respectivamente –1 e -2. Para adição de um diretório/sub-diretório ou arquivo é necessário saber se há espaço livre na FAT e conseqüentemente no disco. No caso de um diretório precisamos apenas de uma entrada, no caso de um arquivo calcula-se o número de blocos necessários através da razão do tamanho em bytes do arquivo e o número de bytes do bloco. Caso não exista espaço suficiente disponível uma mensagem de exceção é exibida.

Ao pedir uma entrada livre a FAT, a mesma devolve alguma que tenha –1 como conteúdo correspondendo a uma entrada livre e coloca-se –3 nele para significar que ainda será usado, esse passo é necessário para caso arquivo ocupe mais de um bloco para que a FAT não me devolva a mesma entrada em dois pedidos seguidos. Mudando de –1 para –3 ele não irá me devolver a mesma entrada, e depois de ter alocado as entradas eu as relaciono para fazer o caminho de busca que será feita no disco para preencher o disco.

A FAT (MSDOSFAT) tem um conjunto de entradas correspondente a quantidade de blocos existentes no disco. Essa entrada é a classe MSDOSFATEntry a qual tem apenas um identificador como atributo e o endereço do bloco. Essas entradas são colocadas na Hashtable gerenciadas pela Tabela de Alocação. A FAT tem vários métodos que: retorna toda a hash, adiciona nova entrada, retorna uma entrada armazenada, retorna todos os blocos usados por um arquivo ou diretório, retorna uma entrada livre na FAT e remove uma entrada da Tabela de Alocação de Arquivo.

6.3.3 Disco

A classe Disco aqui simulada corresponde a parte do disco rígido reservadas aos blocos do disco que são gerenciadas (apontadas) pela FAT.

O disco rígido tem a organização mostrada na Figura 6 4, onde a primeira parte corresponde ao diretório raiz, a segunda a FAT e a terceira ao disco que está dividido em blocos de 4K (4096 bytes) cada.

Figura 6 4 Organização do Disco no MS-DOS

A Figura 6 4 mostra a ordem em que a busca por um arquivo ou diretório é executada. Seguindo os números da mesma, vemos que utiliza-se primeiro o caminho (path) para procurar no diretório raiz o sub-diretório mais próximo. Depois vai-se na FAT e ver que bloco corresponde a tal sub-diretório e então obtém-se o sub-diretório a partir do disco. Esse ciclo é feito até encontrar o último sub-diretório do caminho e assim encontra-se também o arquivo, com a diferença que iremos retorna ao cliente a concatenação do conteúdo dos blocos correspondente ao arquivo.

A classe Disco tem uma coleção de entradas que são os blocos, essa coleção é implementada por um Vector. A mesma quantidade de entradas na FAT deve corresponder a quantidade de blocos existentes para garantir consistência. Cada entrada do disco é um bloco. A classe Bloco tem apenas um array de bytes com os métodos obter, atribuir e clone. Os métodos do Disco (classe) são escrever, ler e remover dados(bytes) de um dado bloco.

Esses dados inseridos em cada bloco podem corresponder a dados de um arquivo, ou a uma estrutura de diretório com seus arquivos e sub-diretórios.

6.3.4 Interface

A interface de interação do sistema de arquivo com o us