Dissertacao TatianaSimasStanchi

UNIVERSIDADE FEDERAL DA PARABA
Centro de Cincias e Tecnologia Coordenao de Ps-Graduao em Informtica
DISSERTAO DE MESTRADO
SALIUS - SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS
por
Tatiana Simas Stanchi
Campina Grande / Paraba 2000
UNIVERSIDADE FEDERAL DA PARABA

Centro de Cincias e Tecnologia Coordenao de Ps-Graduao em Informtica
Tatiana Simas Stanchi
SALIUS - SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS
Dissertao apresentada ao curso de Mestrado em Informtica da Universidade Federal da Paraba, em cumprimento s exigncias para obteno do Grau de Mestre.
rea de Concentrao: Sistemas Distribudos Orientador: Francisco Vilar Brasileiro
Campina Grande / Paraba 2000
S784S
STANCHI, Tatiana Simas SALIUS - SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS. Dissertao de Mestrado, Universidade Federal da Paraba, Centro de Cincias e Tecnologia, Coordenao de Ps-Graduao em Informtica, Campina Grande - Pb, fevereiro de 2000. 127 p. Il. Orientador: Francisco Vilar Brasileiro.
Palavras Chave: 1. Sistemas Distribudos 2. Armazenamento Estvel 3. Sistema de Arquivos Robusto 4. Tolerncia a Falhas
CDU - 681.3.066D
Resumo
Armazenamento estvel um requisito importante para muitas aplicaes. Os sistemas de arquivos tradicionais realizam a gravao sncrona em disco, como uma forma de garantir a estabilidade dos dados armazenados. Contudo, a gravao sncrona provoca uma degradao no desempenho das aplicaes, em decorrncia da lentido dos acessos a disco. medida que a tecnologia evolui, aumentam os prejuzos no desempenho, causados pelo uso da gravao sncrona. Os avanos tecnolgicos no acontecem no mesmo ritmo para todos os componentes de hardware: a velocidade dos processadores aumenta em propores bem maiores que a velocidade de acesso a disco. Por isso, o tempo de acesso a disco um entrave crescente ao desempenho de aplicaes que realizam muitas operaes de escrita, especialmente se a gravao for sncrona. Esta dissertao apresenta a especificao de uma nova tcnica de armazenamento estvel, denominada SALIUS SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS. A tcnica proposta substitui a gravao sncrona pela replicao remota de buffers alterados na cache. Assim, a aplicao deixa de esperar pela operao de sada para disco, passando a aguardar pelo envio dos dados alterados atravs da rede e o armazenamento desses dados na memria principal de uma mquina remota. Como a velocidade de acesso memria principal progressivamente maior que a velocidade de acesso a disco, enquanto a transmisso de dados, atravs de uma rede de alta velocidade, bem mais veloz do que a gravao da mesma quantidade de dados em disco, o principal benefcio oferecido a garantia de estabilidade dos dados, com um desempenho potencialmente superior ao de solues baseadas na gravao sncrona em disco. A tcnica proposta tende a ser cada vez mais vantajosa, porque a tecnologia de memria e a tecnologia de rede progridem num ritmo mais acelerado que a tecnologia de disco. Para assegurar a estabilidade das informaes, a tcnica proposta inclui um mecanismo de recuperao para frente, capaz de restaurar o sistema de arquivos para um estado consistente, aps um crash. i
Abstract
Stable storage of data is an important requirement for many applications. Traditional file systems use synchronous writing to disk as a way of guaranteeing the stability of stored data. However, synchronous writing impairs application performance because of the slow speed of disk access. As hardware technology advances, impairment to performance caused by the use of synchronous writing increases. The hardware component technologies develop at varying rates. The speed of processors is increasing at a greater rate than the speed of disk access. Thus disk access time is limiting the performance of applications which perform many disk access operations, especially in the case of synchronous writing. This dissertation presents the specification of a new stable storage technique, called SALIUS STABLE STORAGE SERVICE WITH FORWARD RECOVERY BASED ON REMOTE REPLICATION OF BUFFERS. The proposed service substitutes synchronous writing with remote replication of buffers that are modified in the cache. In this way the application does not wait for output to disk but instead waits for the sending of modified data through a network and the storage of this data in the main memory of a remote machine. The main advantage of the proposed service is the guarantee of stability, with a potentially better performance than the solutions based on synchronous writing, due to the fact that the speed of memory access is progressively greater than that of disk access, and the transfer of data through a high speed network is considerably faster than writing the same quantity of data to disk. Since memory and network technologies are developing at a considerably greater speed than that of disk technology, this approach could be even more advantageous. To assure the stability of the information, the technique includes a forward recovery mechanism which allows it to collect enough remote information to restore the file system to a consistent state after a crash.
ii
Dedico esse trabalho minha querida filha Malu, fonte de toda a minha inspirao.
iii
Agradecimentos
O percurso trilhado durante um curso de mestrado nem sempre fcil e tranqilo. Agradeo a Deus a oportunidade de realizar esse trabalho e de aprender um pouco mais sobre a Arte de Viver. Minha eterna gratido aos meus pais, Arlindo (in memorian) e Ana Lcia, sempre presentes com palavras de carinho e incentivo, de prontido para atender s minhas solicitaes. Sem eles, seria impossvel cumprir essa jornada. Agradeo minha filhinha Malu, pela cumplicidade e compreenso, diante da falta de tempo e de tantas prioridades, que subtraram-lhe horas de convvio e ateno. Sou igualmente grata minha irm Ktia, pela valiosa ajuda nos momentos difceis e por torcer pelo meu sucesso, e a Edil, pelo companheirismo e por desejar a realizao de meus sonhos e projetos. Um agradecimento muito especial ao meu grande amigo e orientador Fubica, que tornou possvel a realizao de um sonho antigo, sabendo desempenhar, com competncia, cada um desses papis. Minha gratido aos meus professores e amigos Raimundo Macdo e Francisco Drea (in memorian), que despertaram o meu interesse para a rea acadmica e foram grandes exemplos, e ao Prof. Marcus Sampaio, por instigar a minha vinda para esse curso. Agradeo, tambm, aos colegas da Procuradoria, que tanto me incentivaram. No poderia esquecer de agradecer inestimvel contribuio daqueles que fazem tudo acontecer: os funcionrios do DSC, especialmente as secretrias da COPIN, Aninha e Vera, sempre muito prestativas; D. Ins, pela maravilhosa tapioca com queijo, e as minhas ajudantes, Cona e Zoraide, que cuidaram bem de minha casa, da minha filha e de mim. Finalmente, um agradecimento enorme aos meus amigos e amigas, companheiros de vida, de Campina Grande (vindos de tantos lugares), de Salvador e de Recife, que me deram a fora necessria para realizar esse sonho, compartilhando risos e lgrimas. A tentativa de cit-los poderia incorrer na injustia de algum esquecimento.
iv
Lista de Figuras
Figura 1.1: Grfico comparativo entre a replicao e a gravao sncrona de um buffer.....................................................................................................5 Figura 1.1: Grfico comparativo entre a replicao e a gravao sncrona de um buffer.....................................................................................................5 Figura 2.2: Diagrama da manipulao de arquivos no Unix....................13 Figura 2.2: Diagrama da manipulao de arquivos no Unix....................13 Figura 2.2: Organizao de um sistema de arquivos do Unix, no disco...15 Figura 2.3: Blocos endereados por um n-i de um arquivo Unix............15 Figura 2.4: Tabelas internas do sistema de arquivos do Unix...................17 Figura 2.5: Vises do sistema de arquivos nos clientes NFS.....................26 Figura 2.6: Arquitetura do NFS...................................................................27 Figura 3.1: Exemplo de RAID Nvel 4.........................................................34 Figura 4.1: Uma comparao da organizao de disco do LFS com a do Unix.................................................................................................................46 Figura 4.2: Distribuio de dados nos sistemas Zebra e xFS...................49 Figura 5.3: Funcionamento bsico do SALIUS..........................................65 Figura 5.3: Funcionamento bsico do SALIUS..........................................65 Figura 5.2: Diagrama da manipulao de arquivos no Unix com SALIUS. 74
Figura 5.3: Estado de um sistema de arquivos na ocasio de um crash...78 Figura 5.4: Sistema de arquivos da Figura 5.3, aps gravao dos dados. 79 Figura 5.5: Sistema de arquivos da Figura 5.3, aps a recuperao........80 Figura 5.6: Estado de um sistema de arquivos na ocasio de um crash...81 Figura 5.7: Sistema de arquivos da Figura 5.6, aps gravao dos dados. 82 Figura 5.8: Sistema de arquivos da Figura 5.6, aps a recuperao........83 Figura 5.9: Sistema de arquivos antes do crash.........................................84 Figura 5.10: Restaurao do sistema de arquivos da Figura 5.9..............84 Figura 5.11: Situao especial na recuperao de um crash.....................85 Figura 6.1: Replicao Passiva.....................................................................94 Figura 6.2: Replicao Ativa........................................................................95
vi
Lista de Tabelas
Tabela 1.1: Resultados dos testes de viabilidade..........................................5 Tabela 2.1: Caractersticas das memrias utilizadas na simulao do sistema eNVy..................................................................................................57 Tabela 4.1: Quadro comparativo de trabalhos relacionados....................59 Tabela 5.1: Flags da operaco open, no SALIUS para Unix.....................68 Tabela 5.2: Primitivas do SALIUS..............................................................73 Tabela 5.3: Dados replicados pelas primitivas do SALIUS.......................75 Tabela 7.1: Quadro comparativo do SALIUS com trabalhos relacionados.................................................................................................116
vii
Sumrio
Resumo _____________________________________________________ i Abstract ____________________________________________________ ii Dedicatria _________________________________________________ iii Agradecimentos _____________________________________________ iv Lista de Figuras _______________________________________________ v Lista de Tabelas _____________________________________________ vi 1 Introduo.....................................................................................................1 1.1 Objetivo....................................................................................................2 1.2 Armazenamento Estvel..........................................................................2 1.3 Replicao................................................................................................2 1.4 Enfoque da Pesquisa................................................................................3 1.5 Estudo de Viabilidade..............................................................................4 1.6 Cenrio de Aplicao...............................................................................6 1.7 Contribuies da Dissertao...................................................................7 1.8 Organizao da Dissertao.....................................................................8 2 Sistema de Arquivos Tradicional..............................................................10 2.1 Evoluo dos Sistemas de Arquivos......................................................11 2.2 Sistema de Arquivos do Unix................................................................12
2.2.1 Manipulao de Arquivos........................................................................13 2.2.2 Implementao........................................................................................14
viii
2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.2.5 2.2.2.6
Organizao do Disco.................................................................................14 Endereamento de Blocos...........................................................................15 Gerncia do Espao Livre...........................................................................16 Tabelas Internas...........................................................................................16 Buffer Cache................................................................................................17 Unix FFS.....................................................................................................18
2.2.3 Armazenamento Estvel no Unix............................................................19 2.2.4 Procedimento de Recuperao do Unix ..................................................20
2.3 Tcnicas de Otimizao do Desempenho..............................................21

2.3.1 Tcnicas que Utilizam Memria Principal..............................................21
2.3.1.1 Caching de Leitura......................................................................................21 2.3.1.2 Leitura Antecipada......................................................................................22 2.3.1.3 Caching de Escrita.......................................................................................22
2.3.2 Tcnicas de Otimizao de Disco............................................................23

2.3.2.1 Caching de Trilha........................................................................................23 2.3.2.2 Tcnicas de Alocao..................................................................................24 2.3.2.3 Tcnicas de Escalonamento.........................................................................25
2.4 Sistema de Arquivos em Rede...............................................................25

2.4.1 Arquitetura do NFS.................................................................................26 2.4.2 Localizao de Arquivos no NFS............................................................28 2.4.3 Caching no NFS......................................................................................28
2.5 Concluses.............................................................................................29 3 Evoluo Tecnolgica e o Novo Desafio...................................................30 3.1 Tecnologia para Sistemas de Arquivos..................................................31
3.1.1 Tecnologia de Processador......................................................................31 3.1.2 Tecnologia de Disco................................................................................32
3.1.2.1 Tecnologia RAID........................................................................................33 3.1.2.2 Tecnologia de Armazenamento tico.........................................................35
3.1.3 Tecnologia de Memria...........................................................................36 3.1.4 Tecnologia de Rede.................................................................................37
3.2 Demanda de Armazenamento das Aplicaes.......................................38 3.3 Tendncias da Tecnologia......................................................................40

3.3.1 Discos de Estado Slido..........................................................................41
3.4 Tendncias das Aplicaes....................................................................42 3.5 Enfoque das Pesquisas Atuais................................................................42 3.6 Concluses.............................................................................................44
ix
4 Sistemas de Arquivos Robustos: Estado da Arte....................................45 4.1 Sistema de Arquivos Baseado em Log..................................................45
4.1.1 Localizao e Leitura de Dados...............................................................47 4.1.2 Recuperao de Crash.............................................................................47 4.1.3 Gerncia de Espao Livre........................................................................48 4.1.4 Sistemas Distribudos Baseados em Log.................................................48 4.1.5 Resultados e Anlise Crtica....................................................................49
4.2 Cache de Memria No-Voltil.............................................................50

4.2.1 Memria No-Voltil na Cache de Cliente..............................................51 4.2.2 Memria No-Voltil na Cache de Servidor............................................52 4.2.3 Dificuldades na utilizao de NVRAM...................................................52 4.2.4 Resultados Obtidos..................................................................................52 4.2.5 Anlise Crtica.........................................................................................53
4.3 Rio File Cache........................................................................................53

4.3.1 Proteo de Memria...............................................................................53 4.3.2 Mecanismo de Recuperao....................................................................54 4.3.3 Efeitos no Projeto de Sistema de Arquivos..............................................54 4.3.4 Suporte de Arquitetura Necessrio..........................................................55 4.3.5 Resultados e Anlise Crtica....................................................................55
4.4 Sistema de Armazenamento em Memria No-Voltil.........................56

4.4.1 Sistema eNVy..........................................................................................57 4.4.2 Anlise Crtica.........................................................................................58
4.5 Concluses.............................................................................................58 5 Especificao do SALIUS..........................................................................60 5.1 Principais Objetivos...............................................................................61 5.2 Requisitos...............................................................................................61

5.2.1 Semntica de Falha..................................................................................61 5.2.2 Semntica de Compartilhamento.............................................................62 5.2.3 Transparncia..........................................................................................62 5.2.4 Facilidade de Administrao...................................................................63 5.2.5 Independncia de Hardware Especial......................................................63
5.3 Funcionamento Geral do SALIUS.........................................................63

5.3.1 Tratamento de Falha na Replicao.........................................................66
5.4 Interface do SALIUS.............................................................................67

5.4.1 open.........................................................................................................68
x
5.4.2 s_creat.....................................................................................................69 5.4.3 write........................................................................................................70 5.4.4 s_mkdir....................................................................................................71 5.4.5 s_mknod..................................................................................................71 5.4.6 s_link.......................................................................................................71 5.4.7 s_unlink...................................................................................................72 5.4.8 s_chown e s_chmode...............................................................................72
5.5 Servidor de Arquivos Complementar....................................................73

5.5.1 Informaes Replicadas pelo SALIUS....................................................74
5.5.1.1 Informaes replicadas pela primitiva s_creat............................................76 5.5.1.2 Informaes replicadas pela primitiva open................................................76 5.5.1.3 Informaes replicadas pela primitiva write...............................................77
5.6 Procedimento de Recuperao ..............................................................77

5.6.1 Efeitos do Procedimento de Recuperao................................................78 5.6.2 Restaurao do Sistema de Arquivos.......................................................83 5.6.3 Situao Atpica......................................................................................85 5.6.4 Recuperao de Dados Gravados por Primitivas do Unix.......................86 5.6.5 Desempenho do Mecanismo de Recuperao do SALIUS......................86
5.7 Consideraes sobre Desempenho e Confiabilidade.............................86

5.7.1 Influncias da Tecnologia........................................................................86 5.7.2 Influncias do Servio de Replicao de Buffers....................................88
6 Projeto de um Servio de Replicao de Buffers.....................................90 6.1 Requisitos do Servio de Replicao de Buffers...................................90 6.2 Grupo de Rplicas..................................................................................91
6.1.1 A Composio do Grupo de Rplicas......................................................92 6.1.2 A Consistncia das Rplicas....................................................................92
6.2 Modelo de Replicao............................................................................93

6.2.1 Replicao Passiva..................................................................................93 6.2.2 Replicao Ativa.....................................................................................94 6.2.3 Modelo de Replicao do SALIUS.........................................................95
6.3 Protocolo de Comunicao....................................................................96 6.4 Protocolo de Replicao........................................................................98

6.4.1 Informaes de Controle de um Pedido de Replicao............................98
6.4.1.1 Informaes Relacionadas com a Entrega das Mensagens.........................99 6.4.1.2 Informaes para a Limpeza dos Logs de Replicao ...............................99 xi
6.4.1.3 Informaes para o Procedimento de recuperao......................................99
6.4.2 Operaes do Protocolo de Replicao..................................................100 6.4.3 Algoritmo de Replicao.......................................................................101 6.4.4 Algoritmo de Regenerao de uma Rplica...........................................106 6.4.5 Algoritmo de Recuperao....................................................................108
6.5 Processamento nas Rplicas................................................................109

6.5.1 Limpeza dos Logs de Replicao..........................................................109
6.6 Consideraes Finais...........................................................................110 7 Concluses.................................................................................................112 7.1 Sumrio da Dissertao........................................................................112 7.2 Anlise do Trabalho.............................................................................114 7.3 Trabalhos Futuros ...............................................................................116 8 Bibliografia................................................................................................118 9 Dados Replicados pelas Primitivas do SALIUS.....................................125
xii
Captulo 1
1 Introduo
A evoluo tecnolgica exerce uma forte influncia nas pesquisas de sistemas computacionais. medida que a tecnologia avana, as caractersticas dos componentes de hardware mudam, exigindo que os algoritmos utilizados para gerenciar os sistemas sejam reexaminados e que novas tcnicas sejam desenvolvidas. As influncias tecnolgicas so particularmente evidentes nos projetos de sistema de arquivos: algumas tcnicas desenvolvidas nas duas ltimas dcadas j se tornaram obsoletas. Um grande problema enfrentado pelos sistemas de arquivos o ritmo evolutivo heterogneo dos componentes de hardware. O projeto de um sistema de arquivos depende da tecnologia de processador, de memria principal, de disco e, mais recentemente, da tecnologia de rede. Nas duas ltimas dcadas, processadores, memrias principais e redes melhoraram por vrias ordens de grandeza, tanto em desempenho, quanto em capacidade. A tecnologia de disco no acompanhou esse desenvolvimento, no que tange ao desempenho, em decorrncia das limitaes impostas pela natureza mecnica dos discos magnticos. A evoluo desigual dos componentes de hardware desafia os sistemas de arquivos a compensarem a lentido dos discos, permitindo que o desempenho cresa com a tecnologia de processador, de memria e de rede. O aumento do desempenho dos sistemas de arquivos deve superar o dos discos. Caso contrrio, as aplicaes sero incapazes de utilizar o rpido aumento da velocidade de processadores e dos demais componentes de hardware, para oferecer um melhor desempenho aos seus usurios. Tradicionalmente, os sistemas de arquivos adotam tcnicas de otimizao de desempenho baseadas na utilizao de memria principal. Porm, essas tcnicas reduzem a confiabilidade do sistema, em decorrncia da volatilidade da memria.
Captulo 1 Introduo 1
Algumas aplicaes necessitam de armazenamento estvel de dados, ou seja, no admitem a perda de informaes, mesmo que ocorram falhas no sistema. Nesse caso, as tcnicas de otimizao baseadas apenas em memria principal no podem ser utilizadas, porque um crash no sistema apaga todo o contedo da memria voltil. Uma soluo bastante simples, para crashes provocados pela interrupo do fornecimento de energia, a utilizao de nobreaks. Porm, essa soluo no atende aos casos de crash do sistema operacional. Os sistemas de arquivos tradicionais oferecem a gravao sncrona, como uma forma de prover armazenamento estvel: a aplicao solicita ao sistema que inicie imediatamente a gravao, em disco, dos dados de uma requisio de escrita e espera pela finalizao da operao de sada. Portanto, os sistemas de arquivos tradicionais obrigam as aplicaes a pagarem um alto custo pelo armazenamento estvel de dados, porque a gravao sncrona vincula o desempenho do sistema ao desempenho dos discos.
1.1 Objetivo
Este trabalho tem como objetivo apresentar a especificao de uma nova tcnica de armazenamento estvel, denominada SALIUS1 SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS , como uma alternativa gravao sncrona em disco. A idia fundamental garantir a sobrevivncia de todos os dados armazenados atravs do uso das primitivas do servio, no caso da ocorrncia de um crash no sistema, e, durante o funcionamento normal, possibilitar um desempenho superior ao obtido por sistemas que adotam a gravao sncrona.
1.2 Armazenamento Estvel

Um armazenamento dito estvel quando o seu contedo preservado de falhas, ou seja, ocorrendo uma falha, os dados armazenados no so destrudos [Jal94]. Vrios tipos de falhas podem ameaar o contedo de um sistema de arquivos, tais como: crash no sistema, falhas no dispositivo de armazenamento, falhas na memria principal, dentre outras. Este trabalho concentra-se apenas em falhas do tipo crash: aps uma primeira omisso, o sistema deixa de produzir respostas para as entradas subseqentes, at que seja reiniciado [Cri91], fazendo com que todo o contedo da memria voltil seja apagado. Portanto, para este trabalho, um armazenamento considerado estvel quando os dados estiverem gravados em um meio de armazenamento no-voltil, como os discos.
1.3 Replicao
1
SALIUS (do latim) eram os doze sacerdotes de Marte, encarregados da guarda dos escudos sagrados que protegiam a estabilidade da Roma Antiga. Captulo 1 Introduo 2
A replicao possibilita a construo de servios tolerantes a faltas, atravs da reproduo de recursos vitais para o sistema, em componentes com modos independentes de falha. A replicao pode envolver tanto recursos de software, quanto de hardware [Lit92]. A replicao de recursos numa mesma mquina denominada replicao local, enquanto a replicao de recursos em diferentes mquinas de um sistema uma replicao remota. A replicao de dados e informaes de controle possibilita a recuperao de crashes: ao reiniciar, um sistema pode restaurar seu estado anterior ao crash e voltar a operar normalmente. O servio de armazenamento estvel apresentado nesta dissertao realiza a replicao remota de buffers da cache de arquivos. Assim, aps um crash, os dados e os metadados de um sistema de arquivos podem ser recuperados, a partir de uma cpia existente em outra mquina, restaurando o sistema de arquivos para um estado consistente.
1.4 Enfoque da Pesquisa

A pesquisa apresentada nesta dissertao focaliza o sistema de arquivos do U NIX [RT78] [MJL+84], como ponto de partida para a discusso sobre armazenamento estvel. A pesquisa parte do estudo de um modelo tradicional de sistema de arquivos, aqui representado pelo sistema de arquivos do UNIX, para analisar como os avanos tecnolgicos influenciam na evoluo das tcnicas de otimizao de desempenho, ao tempo em que tornam iminente o surgimento de novas tcnicas de armazenamento estvel. Existem muitas vantagens em eleger o sistema UNIX como o foco inicial de uma pesquisa na rea de sistema de arquivos: a maioria de aplicaes UNIX faz uso intensivo do sistema de arquivos; as requisies de armazenamento no ambiente UNIX so diversificadas, variando tanto em tamanho, quanto na natureza, seqencial ou randmica. Trata-se de um sistema de arquivos amplamente utilizado, o qual tem sido objeto de muitas pesquisas, havendo uma rica bibliografia disponvel. O trabalho apresenta uma especificao do Servio de Armazenamento Estvel com Recuperao para Frente Baseado na Replicao Remota de Buffers, voltada para o ambiente UNIX [Bac86]. Como idia fundamental do servio proposto a replicao remota de dados alterados na cache de arquivos, trata-se de um projeto destinado a um ambiente distribudo. Por isso, o servio de armazenamento estvel proposto utiliza a capacidade de comunicao via rede do UNIX, para realizar a replicao.
Embora a especificao apresentada neste texto enfoque o sistema UNIX, a replicao remota de informaes da cache de arquivos, como uma alternativa gravao sncrona de
dados, tambm pode ser aplicada a outros sistemas de arquivos. Assim, a tcnica de armazenamento estvel proposta tem um sentido genrico, embora o sistema de arquivos do UNIX seja utilizado como contexto para a sua descrio.
1.5 Estudo de Viabilidade

O primeiro passo dessa pesquisa consistiu na realizao de testes de viabilidade, com o objetivo de comparar o tempo da gravao sncrona de um buffer com o tempo de replicao do mesmo buffer, na memria principal de outra mquina do sistema. Os testes foram realizados no Laboratrio de Sistemas Distribudos da Universidade Federal da Paraba, utilizando-se dois microcomputadores, ambos com processadores Intel 486 e discos com tempo de acesso de oito milissegundos, executando sistema operacional Linux [BBD+97], cuja verso do ncleo era 2.0.29. Os equipamentos estavam interligados atravs de uma rede padro Ethernet, com taxa de transmisso de at dez megabits por segundo. Os programas de teste foram escritos na linguagem C e a comunicao entre processos das duas mquinas foi estabelecida atravs de sockets [Ste92], utilizando protocolos TCP/IP [CS91] [CS93]. Foram realizados dois procedimentos de medio, sendo um para a gravao sncrona de um buffer e o outro para a replicao de um buffer idntico. Os procedimentos foram executados para tamanhos de buffers diferentes, com uma repetio de cem vezes, para cada tamanho de buffer. O procedimento de medio da gravao sncrona utilizou um programa que preenchia o buffer e contava o tempo em milissegundos, necessrio para realizar a gravao em disco. O procedimento de medio da replicao utilizou dois programas: o primeiro, denominado de cliente, executado na mquina de origem, cuja funo era preencher o buffer e computar o tempo em milissegundos, necessrio para envi-lo a uma outra mquina e receber um reconhecimento. O segundo programa, denominado servidor, executado na mquina destinatria, que recebia o buffer e retornava um reconhecimento. A pretenso desses testes nunca foi chegar a resultados deterministas. Visaram apenas evitar a insistncia em desenvolver um projeto que no tivesse possibilidades de xito. Os resultados obtidos foram animadores e serviram de incentivo para que o projeto fosse posto a termo. A Tabela 1.1 exibe o tempo mdio de replicao e o tempo mdio de gravao sncrona, em milissegundos, calculados para cada tamanho de buffer. Os resultados demonstraram
que a replicao bastante vantajosa para buffers pequenos: replicar um buffer de um kilobyte vinte e cinco vezes mais rpido do que grav-lo no disco.
Tamanho do buffer (KB) 0,5 1 4 6 8 12 14 16 24
Tempo mdio de replicao (ms) 0,9 1 6,2 15 16,4 24,3 25,2 34,1 43,2
Tempo mdio de gravao sncrona (ms) 20 25,5 28,1 29 30,1 31,5 32,8 33,8 35,4
Tabela 1.1: Resultados dos testes de viabilidade.
O grfico da Figura 1.1 demonstra o comportamento do tempo mdio de replicao e do tempo mdio de gravao sncrona: medida que o tamanho do buffer aumenta, a vantagem da replicao diminui; quando o buffer atinge dezesseis kilobytes, o tempo mdio praticamente o mesmo, para ambos os procedimentos; para buffers maiores, a replicao deixa de ser vantajosa. Portanto, existe um tamanho mximo de buffer (B-max), aps o qual a replicao passa a ser mais lenta do que a gravao sncrona em disco.
Tempo (ms)
Teste Comparativo
50 40 30 20 10 0 0 4 8 12 16 20 24 28
Replicao Gravao Sncrona
Tamanho do Buffer (KB) Figura 1.1: Grfico comparativo entre a replicao e a gravao sncrona de um buffer. primeira vista, portanto, a replicao seria vantajosa, apenas, para sistemas de arquivos com blocos de tamanho pequeno. Porm, uma anlise mais detalhada poderia demonstrar que o tamanho mximo de buffer (B-max) varia de acordo com as caractersticas dos
componentes de hardware do sistema (o item 5.7 apresenta as influncias dos componentes de hardware no desempenho da replicao). O B-max derivado da relao entre o tempo mdio de gravao sncrona (TmG) e o tempo mdio de replicao (TmR): se o TmG diminui, ento, o B-max diminui; se o TmR diminui, ento, o B-max aumenta. O tempo mdio de gravao sncrona depende do tempo de acesso a disco: quanto mais rpido o acesso a disco, menor o TmG e tambm menor o B-max. No entanto, as tendncias tecnolgicas apontam para uma melhoria muito tmida do tempo de acesso a disco, em relao aos demais componentes de hardware. Assim, o TmG tende a uma variao muito pequena. O tempo mdio de replicao depende da taxa de transmisso de dados na rede e do tempo de acesso memria principal: quanto mais velozes forem os acessos memria e a transmisso atravs da rede, menor o TmR e maior o B-max. Assim, com o uso de rede de alta velocidade e de memria com tempo de acesso reduzido, pode-se aumentar significativamente o B-max. As tendncias tecnolgicas apontam para um grande aumento na velocidade das redes e para um aumento na velocidade de acesso memria principal bem superior ao crescimento da velocidade de acesso a disco. Assim, as tendncias da tecnologia indicam um provvel crescimento progressivo de B-max. Os testes realizados foram considerados satisfatrios, tendo-se em vista as tendncias da tecnologia e os seguintes fatores: os testes utilizaram uma rede local, com taxa de transmisso mxima de dez megabits por segundo, sendo que atualmente esto disponveis redes com taxas de transmisso bem maiores, de cem megabits, ou na ordem de gigabits por segundo, que devem levar a um aumento no tamanho mximo de buffer; os testes utilizaram os protocolos de comunicao TCP/IP. Por ser orientado conexo e garantir a entrega confivel de mensagens, o TCP incorpora uma sobrecarga de processamento que retarda a transmisso de dados em uma rede convencional; os testes utilizaram processadores Intel 486, capazes de executar, aproximadamente, vinte MIPS (Milhes de Instrues Por Segundo). Atualmente, esto disponveis equipamentos com processadores mais velozes (mais de 500 MIPS) [Int97]; a quantidade de informaes normalmente trafegadas pelo servio pequena. Quando um bloco alterado, o servio envia uma mensagem de replicao contendo o contedo do bloco e um cabealho com informaes de controle, cujo tamanho de apenas algumas poucas dezenas de bytes. Assim, a quantidade de dados trafegados apenas ligeiramente maior que o tamanho do bloco do arquivo (a maioria dos sistemas de arquivos do UNIX utiliza blocos pequenos, sendo 4Kb o tamanho mais adotado).
1.6 Cenrio de Aplicao
Captulo 1 Introduo
medida que proliferam os sistemas computacionais ligados atravs de rede, crescem os clientes em potencial do SALIUS. Com o grande desenvolvimento da Internet, muitos servios novos passaram a ser oferecidos. Alguns destes servios requerem alta confiabilidade no armazenamento secundrio de informaes. Um cenrio tpico de aplicao do SALIUS consiste de um servidor de transaes, que utiliza um sistema de arquivos local para a gravao de seus logs. Como as informaes contidas em um log so imprescindveis para a recuperao de informaes gravadas por transaes j confirmadas, os dados de um log precisam de armazenamento estvel. Num sistema de arquivos tradicional, esses dados seriam armazenados atravs de gravao sncrona, o que acarretaria uma perda no desempenho. Estando o servidor de transaes ligado a uma rede local, o SALIUS pode ser utilizado para prover armazenamento estvel, evitando os atrasos introduzidos pelas gravaes sncronas. Sistemas de banco a domiclio e de comrcio eletrnico so exemplos tpicos de aplicaes que poderiam usar esse servio de transaes munido do SALIUS. Por exemplo, quando um cliente de um sistema de banco a domiclio deseja solicitar uma movimentao em sua conta, ele envia um formulrio com os dados necessrios. Ao receber tais informaes, o servidor deve realizar a transao solicitada e enviar uma resposta ao cliente. Os dados da transao precisam ser assegurados. Por isso, o servidor de transaes grava toda a movimentao num arquivo de log, que ser utilizado para aes de recuperao aps um crash. Num sistema de arquivos convencional, a aplicao deveria esperar pela gravao sncrona dos dados do log. Utilizando o SALIUS, os dados do log so replicados na memria principal de mquinas da rede local do servidor de transaes. Como a replicao potencialmente mais rpida do que a gravao sncrona em disco, com o servio oferecido pelo SALIUS, a aplicao pode garantir um melhor tempo de resposta. Adicionalmente, o mecanismo de recuperao para frente do SALIUS garante a restaurao dos dados do log, caso o servidor de transaes sofra um crash.
1.7 Contribuies da Dissertao

As principais contribuies deste trabalho so: a especificao de uma nova tcnica de armazenamento estvel, potencialmente capaz de substituir, de forma vantajosa, as solues baseadas apenas na gravao sncrona em disco. Tomando-se como base as velocidades de acesso a disco, as taxas de transmisso das redes de alta velocidade e as velocidades de acesso memria principal, disponveis atualmente, uma implementao eficiente do SALIUS dever levar a um desempenho superior ao armazenamento atravs de gravao sncrona em disco; o servio proposto independente de hardware especial. A maioria dos trabalhos recentes, que visam aumentar a confiabilidade do armazenamento de dados, depende da utilizao de um hardware especial, o que quase sempre acarreta altos custos. A
7
Captulo 1 Introduo
tcnica de armazenamento estvel proposta nesta dissertao, pelo contrrio, utiliza a tecnologia atualmente disponvel na maioria dos sistemas computacionais; o SALIUS possibilita que os avanos tecnolgicos em curso beneficiem mais o sistema, porque consegue diminuir a influncia da tecnologia de disco no desempenho global do sistema: eliminando a urgncia de gravar dados em disco, o servio permite que o sistema utilize mais agressivamente as tcnicas de otimizao de desempenho, baseadas no armazenamento em memria principal. O desempenho do sistema passa a depender mais dos processadores, da capacidade de memria disponvel, da velocidade de acesso memria, das taxas de transmisso da rede e da banda passante da rede disponvel para esse servio, enfraquecendo o vnculo existente com a tecnologia de disco; o SALIUS pode ser utilizado por sistemas de arquivo de propsito geral; o SALIUS assegura a estabilidade de todos os dados armazenados, atravs do uso de suas primitivas, incluindo as ltimas alteraes realizadas sobre o sistema de arquivos antes de um crash. Para isso, o servio adota um protocolo de replicao capaz de garantir a existncia de, pelo menos, uma cpia dos dados alterados na cache de arquivos, e um mecanismo de recuperao que utiliza essa cpia para restaurar o sistema de arquivos; o SALIUS capaz de tolerar crash de sistema operacional; o mecanismo de recuperao do servio simples e potencialmente rpido: no preciso verificar todos os metadados do sistema de arquivos, detendo-se apenas aos dados e metadados possivelmente afetados pelo crash, ou seja, aqueles que foram alterados na memria principal e replicados.
1.8 Organizao da Dissertao

Este documento est organizado em seis captulos. O prximo captulo descreve o sistema de arquivos do UNIX, que utilizado como contexto do trabalho, e a tcnica de armazenamento estvel baseada na gravao sncrona em disco. Adicionalmente, discutem-se as principais tcnicas de otimizao de desempenho adotadas pelos sistemas de arquivos tradicionais. Esse captulo foi includo na dissertao, com o objetivo de agregar ao documento todos os conceitos prvios importantes sua compreenso. Entretanto, para um leitor familiarizado com a estrutura interna do sistema de arquivos do UNIX e com as tcnicas de otimizao de sistemas de arquivos, pode ser conveniente avanar diretamente para o Captulo 3. O Captulo 3 revisa as questes relevantes para as pesquisas na rea de sistema de arquivos, provendo a motivao e a direo deste trabalho. Apresenta os efeitos dos avanos tecnolgicos em curso e as necessidades de armazenamento das novas aplicaes,
evidenciando os novos requisitos que precisam ser contemplados pelos projetos de sistema de arquivos. O Captulo 4 apresenta o estado da arte em sistemas de arquivos robustos, descrevendo e analisando, de forma crtica, os trabalhos relacionados, que visam a melhoria do desempenho e da confiabilidade dos sistemas de arquivos. Esse captulo tambm evidencia o diferencial da tcnica de armazenamento estvel proposta. O Captulo 5 apresenta a especificao do Servio de Armazenamento Estvel com Recuperao para Frente Baseado na Replicao Remota de Buffers. Inicialmente, esse captulo descreve os principais objetivos e requisitos do servio. Em seguida, apresenta o funcionamento geral do servio e descreve mais detalhadamente cada parte componente: a Interface, o Servidor de Arquivos Complementar e sua interao com o Servio de Replicao de Buffers, alm do Procedimento de Recuperao. Finalmente, o captulo apresenta consideraes sobre o desempenho e a confiabilidade do SALIUS. O Captulo 6 apresenta o Projeto de um Servio de Replicao de Buffers, descrevendo os requisitos do servio, as caractersticas do grupo de rplicas, o modelo de replicao utilizado, o protocolo de comunicao e o protocolo de replicao do servio. O Captulo 7 apresenta as concluses obtidas e as sugestes de trabalhos futuros, de continuao dos estudos apresentados nesta dissertao.
Captulo 1 Introduo
Captulo 2
2 Sistema de Arquivos Tradicional
Um sistema de arquivos um subsistema do sistema operacional, cujo propsito prover armazenamento de informaes a longo prazo [LS90]. Para isso, o subsistema armazena dados em unidades denominadas arquivos, em dispositivos de armazenamento secundrio, como os discos [Tan92]. Um sistema de arquivos atende s requisies de usurios, realizando operaes sobre os arquivos, tais como: criao, remoo, leitura e escrita. Projeto de sistema de arquivos uma rea de pesquisa da computao relativamente antiga. Muitos projetos j foram propostos e implementados. Esses projetos adaptam-se s mudanas dos sistemas computacionais, provocadas pela evoluo da tecnologia. Este captulo apresenta uma anlise breve da evoluo dos sistemas de arquivos. A especificao do Servio de Armazenamento Estvel com Recuperao para Frente Baseado na Replicao Remota de Buffers, apresentada nesta dissertao, voltada para o ambiente UNIX [RT78], em decorrncia de vrios fatores, dentre eles: o sistema de arquivos do UNIX amplamente utilizado, tanto na academia, quanto comercialmente; existe uma vasta bibliografia disponvel, documentando o funcionamento desse sistema e as pesquisas realizadas ele. Por isso, este captulo descreve as abstraes bsicas e as tcnicas de implementao do sistema de arquivos do UNIX, como ponto de referncia para a discusso sobre tcnicas de otimizao de sistemas de arquivos e tcnicas de armazenamento estvel. Mais propriamente, este captulo descreve a tcnica de armazenamento estvel empregada pelo sistema de arquivos do UNIX, cujo modelo adotado pela maioria dos sistemas de arquivos tradicionais. Adicionalmente, este captulo apresenta algumas tcnicas de otimizao de sistemas de arquivos, e descreve um sistema de arquivos em rede, o NFS [SGK+85], muito utilizado para a integrao de dados de sistemas de arquivos do UNIX.
Captulo 2 Sistema de Arquivos Tradicional
10
2.1 Evoluo dos Sistemas de Arquivos

Inicialmente, todos os sistemas de computadores eram centralizados, ou seja, compostos por um nico processador, uma memria, alguns perifricos e terminais [Tan92]. Num sistema centralizado, todos os dispositivos de armazenamento secundrio e demais perifricos esto ligados a uma nica CPU. O sistema operacional, normalmente formado por um grande ncleo monoltico, permite que os usurios compartilhem os recursos disponveis. O sistema de arquivos, como um subsistema do sistema operacional, tambm centralizado, atendendo s requisies de todos os usurios. O sistema de arquivos e seus usurios so implementados como processos, executados numa mesma mquina. Durante a dcada de oitenta, o desenvolvimento de microprocessadores com grande poder computacional e a implementao de redes locais, com taxas de transferncia superiores a dez megabits por segundo, alteraram o perfil dos sistemas computacionais. Surgiram sistemas compostos por vrias CPUs, conectadas atravs de redes de alta velocidade [Tan95]. Os sistemas operacionais foram acrescidos de novas funcionalidades, como, por exemplo, os subsistemas de comunicao, que permitem a troca de informaes entre processos executando em mquinas diferentes. Essa facilidade de comunicao possibilitou uma interao cada vez maior entre os sistemas operacionais das diversas mquinas componentes do sistema, at o surgimento de sistemas distribudos: Um sistema distribudo uma coleo de computadores independentes, que aparecem como um nico computador para os usurios do sistema [Tan95]. A discusso sobre sistemas distribudos requer a definio prvia dos conceitos de servio, servidor e cliente [Mitchell. Apud LS90:322]. Um servio um software que pode ser executado em uma ou mais mquinas, provendo uma funo especfica para os clientes. Um servio especifica um conjunto de operaes, cuja execuo pode ser disparada por entradas de clientes, ou pela passagem do tempo [Cri91]. A execuo de uma operao pode resultar em sadas para os clientes, ou em mudanas de estado. Um servidor uma implementao do servio, na forma de um processo, executado em uma mquina do sistema. Um cliente um processo que solicita servios a um servidor, atravs de uma interface. Usando a terminologia previamente definida, um sistema de arquivos distribudo prov servio de arquivos para seus clientes, sendo implementado atravs de um ou vrios servidores de arquivos. A interface do servio de arquivos formada por um conjunto de primitivas e seus respectivos parmetros, usadas pelos clientes, para solicitar que um servidor realize operaes com arquivos, tais como: criao, remoo, leitura e escrita, dentre outras. Os clientes, os servidores e os dispositivos de armazenamento esto espalhados em diversas mquinas [LS90].
Captulo 2 Sistema de Arquivos Tradicional 11
2.2 Sistema de Arquivos do UNIX

O sistema de arquivos do UNIX [RT78] um modelo clssico de sistema de arquivos centralizado. No UNIX, um arquivo tratado como uma seqncia no-estruturada de bytes. O sistema de arquivos atende s requisies de acesso das aplicaes, armazenando ou recuperando uma quantidade de bytes solicitada. A interpretao do contedo do arquivo uma tarefa das aplicaes. Cada arquivo est associado a uma estrutura de dados, denominada de n-i (n ndice), onde o sistema armazena os atributos do arquivo, tais como: tipo, tamanho, tempos da ltima modificao e do ltimo acesso, proprietrio e permisses de acesso. O sistema de arquivos mantm um conjunto de ns-i, numerados seqencialmente. O nmero de um ni um inteiro, que identifica unicamente o arquivo associado. O n-i o ponto de partida para o acesso aos dados de um arquivo, porque armazena uma tabela com os endereos dos blocos do arquivo. As aplicaes referenciam os arquivos por nomes. O sistema de arquivos traduz o nome de um arquivo no nmero do n-i correspondente. Para isso, o sistema utiliza um tipo especial de arquivo, denominado diretrio, que contm pares de nomes de arquivos e seus respectivos nmeros de n-i. Um diretrio pode conter entradas, tanto para nomes de arquivos, quanto para nomes de outros diretrios, permitindo uma organizao hierrquica do sistema de arquivos. Por isso, a estrutura de diretrios representada na forma de uma rvore ou de um grafo. O topo da hierarquia um diretrio raiz, os ns intermedirios so os demais diretrios e as folhas so os arquivos [Tan92]. Quando existem entradas para um mesmo arquivo em mais de um diretrio, a hierarquia assume a forma de um grafo. O n-i do arquivo guarda a informao do nmero de diretrios que referenciam o arquivo. A localizao de um arquivo realizada atravs de um nome de caminho, formado de uma seqncia de nomes componentes, separados por barras simples. Cada componente um nome de arquivo contido no diretrio representado pelo componente anterior [Bac86]. Por exemplo, o nome de caminho /usr/docs/curso referencia o arquivo curso, contido no diretrio docs, o qual est contido no diretrio usr. O sistema converte um nome de caminho no n-i do arquivo correspondente. Para isso, realiza uma pesquisa linear em cada diretrio do nome de caminho, buscando o nmero do n-i do componente seguinte. Se este for outro diretrio, o sistema utiliza o n-i para localizar os seus blocos de dados. A seguir, l o contedo do diretrio, localizando o n-i do prximo componente do nome de caminho e assim, sucessivamente, at chegar ao n-i do arquivo.
12
2.2.1 Manipulao de Arquivos

O UNIX adota o modelo tradicional de acesso a arquivos: primeiro, o arquivo deve ser aberto; seguem as operaes de leitura e/ou escrita e, finalmente, o arquivo deve ser fechado. Para cada arquivo aberto, o sistema mantm um indicador da posio corrente dentro do arquivo. As operaes de acesso comeam na posio corrente. A operao de escrita permite aplicao transferir uma quantidade informada de dados para um arquivo, a partir da posio corrente. A operao de leitura permite que a aplicao leia dados do arquivo para a memria principal, iniciando na posio corrente. Aps cada operao de acesso, o sistema atualiza a posio corrente. Para realizar acessos aleatrios, a aplicao deve, previamente, solicitar que o sistema altere a posio corrente do arquivo. As aplicaes no manipulam diretamente os dados armazenados: requisitam que o sistema de arquivos realize as operaes desejadas [AT89]. O diagrama da Figura 2.1 mostra que o sistema de arquivos do UNIX um componente do ncleo do sistema operacional. Os processos de usurio comunicam-se com o ncleo, invocando as chamadas de sistema, ou atravs de primitivas das bibliotecas de interface, que so vinculadas aos programas do usurio em tempo de compilao [Bac86]. As chamadas de sistema ordenam operaes ao ncleo e realizam a troca de informaes entre o ncleo e os processos de usurio.
Processos de usurio Nvel do usurio
Bibliotecas de interface
Chamadas de sistema Sistema de arquivos buffer cache Drivers dos dispositivos de E/S Nvel do ncleo Nvel do hardware Controladores de hardware Hardware
Figura 2.2: Diagrama da manipulao de arquivos no UNIX.
13
O UNIX oferece aos programas de usurio uma interface com muitas opes de chamadas de sistema [AT89]. As chamadas mais utilizadas so: open, utilizada para abrir ou criar um arquivo; read, que permite a leitura de uma quantidade informada de bytes de um arquivo; write, usada para armazenar dados em um arquivo; close, utilizada para fechar arquivos; mkdir, que serve para criar um novo diretrio; link, que permite a criao de um novo nome de caminho para um arquivo; unlink, utilizada para remover um nome de caminho, ou um arquivo inteiro, e seek, que permite alterar a posio corrente no arquivo. Existem, ainda, chamadas de sistema para recuperar e alterar os atributos do arquivo. O sistema de arquivos do UNIX utiliza um mecanismo de buffering, exibido na Figura 2.1 como buffer cache, que regula o fluxo de dados entre o ncleo do sistema e os dispositivos de armazenamento secundrio. O mecanismo de buffering interage com os drivers dos dispositivos de entrada/sada, para iniciar a transferncia dos dados. Alternativamente, o sistema de arquivos pode interagir diretamente com os drivers dos dispositivos de entrada/sada, sem a interveno do mecanismo de buffering.
2.2.2 Implementao
A implementao inicial do sistema de arquivos do UNIX [RT78] muito simples e no utiliza muitas tcnicas de otimizao. No entanto, a sua descrio importante, pois forma a base para as implementaes subseqentes de sistemas de arquivos para UNIX.
2.2.2.1 Organizao do Disco

Uma instalao do sistema operacional UNIX pode possuir vrios discos, cada um contendo um ou mais sistemas de arquivos [Tan92]. O ncleo trata um sistema de arquivos como um dispositivo lgico, identificado por um nmero de dispositivo e composto de uma seqncia de blocos lgicos [Bac86]. Na implementao inicial, o tamanho dos blocos de um sistema de arquivos fixo e mltiplo de 512 bytes, homogneo num sistema de arquivos, mas podendo variar de um sistema para outro. O driver de disco realiza a converso de um nmero lgico de bloco em um endereo fsico, no disco. A Figura 2.2 ilustra a estrutura de um sistema de arquivos, composta das seguintes regies: Bloco de boot. No utilizado pelo sistema de arquivos. Quando coincide com o bloco zero do disco, contm o cdigo dos procedimentos iniciais, executados assim que o computador ligado. Superbloco. Contm um sumrio de informaes acerca do sistema de arquivo, incluindo a localizao das outras regies; o nmero de arquivos existentes; o prximo n-i livre; o nmero total de blocos livres na regio de dados; informaes para a localizao de blocos livres; alm de informaes de estado, indicando se o sistema est disponvel apenas para leitura e se o contedo do superbloco foi modificado.
14
Lista de ns-i. Uma seqncia de ns-i, com os atributos de arquivos e diretrios. Blocos de dados. Blocos contendo os dados de arquivos e diretrios.
Bloco de boot Superbloco Ns-i Blocos de dados
Figura 2.2: Organizao de um sistema de arquivos do UNIX, no disco.
2.2.2.2 Endereamento de Blocos

No n-i esto armazenados os atributos do arquivo e uma tabela de endereos composta de treze entradas, com endereos de blocos do arquivo. A Figura 2.3 ilustra a tabela de endereos de um n-i. As dez primeiras entradas apontam para blocos diretos, que armazenam dados. As trs entradas restantes endeream blocos indiretos. Um bloco indireto simples armazena endereos de blocos diretos, um bloco indireto duplo armazena endereos de blocos indiretos simples e um bloco indireto triplo armazena endereos de blocos indiretos duplos.
N-i
Atributos Direto 0 Direto 1

Dados
Direto 9 Direto9 Indireto Simples Indireto Duplo Indireto Triplo
Figura 2.3: Blocos endereados por um n-i de um arquivo Unix.
15
2.2.2.3 Gerncia do Espao Livre

O sistema de arquivos do UNIX [RT78] gerencia o espao livre em disco, atravs de uma lista ligada, chamada lista de blocos livres, formada pelos blocos da regio de dados que no esto correntemente alocados para um arquivo ou diretrio. O incio da lista de blocos livres um ponteiro no superbloco, para o primeiro bloco de dados livre. Quando uma operao de escrita, ou de criao de arquivo, requer espao na regio de dados do disco, o sistema aloca blocos da lista. Quando uma operao de remoo, ou de reduo do tamanho de um arquivo, libera espao em disco, os blocos retornam para a lista.
2.2.2.4 Tabelas Internas

Para executar as chamadas de sistema, o sistema de arquivos manipula estruturas de dados auxiliares. So tabelas internas, armazenadas na rea de memria principal reservada ao sistema operacional e, portanto, no so acessveis aos processos de usurio [Tan92]. Tabela de ns-i. O sistema mantm uma entrada na tabela de ns-i para cada arquivo aberto. A cpia de um n-i na tabela nica, mesmo que vrios processos estejam trabalhando com o arquivo, concorrentemente. Alm do n-i, cada entrada da tabela armazena um contador de ligaes, para controlar quantas referncias existem para o arquivo, num determinado momento. O n-i s retirado da tabela quando todos os processos fecham o arquivo e o contador de ligaes assume o valor zero. Tabela de arquivos abertos. Todos os arquivos abertos no sistema possuem entradas na tabela de arquivos abertos. Cada vez que um processo abre um arquivo, o sistema cria uma nova entrada nessa tabela. Assim, num dado momento, podem existir vrias entradas na tabela referenciando um mesmo arquivo. Em cada entrada, esto registrados: o modo como o arquivo foi aberto (apenas para leitura, para leitura e escrita, ou apenas para escrita), a posio corrente no arquivo, onde ser realizada a prxima operao e um apontador para o n-i do arquivo, na tabela de ns-i. Existe, ainda, um contador para controlar o nmero de processos apontando para essa entrada. Tabela de descritores de arquivos. Enquanto a tabela de ns-i e a tabela de arquivos abertos so estruturas globais, o ncleo aloca uma tabela de descritores de arquivos, para cada processo. Quando um processo abre, ou cria um arquivo, o sistema aloca uma nova entrada nessa tabela e retorna para o processo um descritor de arquivo. Nas chamadas de sistema subseqentes, o processo passa a referenciar o arquivo pelo seu descritor, que usado como ndice na tabela de descritores. Cada entrada na tabela de descritores aponta para uma nica entrada na tabela de arquivos abertos.
16
A existncia de dois tipos de tabelas, para controlar os arquivos abertos no sistema, tem o objetivo de possibilitar o compartilhamento da posio corrente de um arquivo entre dois processos. Se a entrada na tabela de descritores apontasse diretamente para o n-i do arquivo, a posio corrente desse arquivo seria armazenada nessa tabela, sendo, portanto, de uso exclusivo do processo. Armazenando a posio corrente do arquivo numa tabela separada, o sistema permite que processos filhos utilizem a mesma posio corrente de um arquivo aberto pelo processo pai [Bac86]. Assim, num dado momento, podem existir vrios apontadores para uma mesma entrada na tabela de arquivos abertos, provenientes de processos diferentes, mas que so relacionados. A Figura 2.4 ilustra as trs tabelas mantidas pelo ncleo. Observando dois arquivos abertos no sistema, o arquivo A e o arquivo B, nota-se que cada um possui uma entrada nica na tabela de ns-i. Seguindo as setas, pode-se observar que o processo 1 abriu o arquivo A duas vezes, primeiro para leitura e, a seguir, para escrita, enquanto o processo 2 abriu o arquivo B para leitura.
Processo 1

3 4 Processo 2

Leitura Escrita Leitura
(arq A)
(arq B)
4 5 Tabelas de descritores Tabela de arquivos abertos Tabela de ns-i
Figura 2.4: Tabelas internas do sistema de arquivos do UNIX.
2.2.2.5 Buffer Cache

Quando um processo de usurio precisa ter acesso a informaes gravadas no disco, ele realiza uma chamada de sistema, requisitando ao ncleo a leitura de blocos do disco para uma rea de trabalho, na memria principal. Se a operao for de escrita, o ncleo realiza a gravao em disco dos dados armazenados na rea de trabalho do processo. Como o acesso a disco muito lento, o sistema reserva uma rea da memria principal, denominada de buffer cache, onde mantm os blocos de disco mais recentemente usados [Bac86].
A cache implementada numa rea de memria de acesso exclusivo do ncleo. Portanto, no pode ser manipulada diretamente por processos de usurio. O sistema armazena os dados lidos do disco na cache, antes de envi-los para a rea de trabalho do processo de usurio. Uma nica chamada de sistema, para realizao de uma leitura, pode preencher vrios buffers da cache. Os dados permanecem por algum tempo na cache, de modo que requisies seguintes, dos mesmos dados, podem dispensar o acesso ao disco. Portanto, o sistema s precisa ler um dado do disco, se este no estiver disponvel na cache. De modo similar, os dados das operaes de escrita so transferidos da rea de trabalho do processo de usurio para a cache. Normalmente, o sistema de arquivos do UNIX realiza a propagao retardada das alteraes: os dados permanecem na cache, por trinta segundos, antes de ser gravados em disco. Nesse intervalo de tempo, vrias operaes de escrita podem ser realizadas sobre um mesmo bloco, sem que sejam propagadas para o disco. Durante o processamento de uma requisio de escrita, o sistema armazena os dados em buffers da cache, marca tais buffers como sujos e devolve imediatamente o controle para o processo de usurio. Portanto, quando uma operao de escrita retorna como bem-sucedida, o processo de usurio no tem a garantia de que os dados sero efetivamente gravados em disco. A ocorrncia de um crash, nos trinta segundos prximos, ocasiona a perda das modificaes realizadas. Para minimizar o risco de perder dados, a cada trinta segundos, o sistema executa a chamada sync, que realiza a gravao em disco de todos os buffers sujos da cache.
2.2.2.6 Unix FFS

A maior reviso do sistema de arquivos do UNIX foi realizada em Berkeley, resultando no UNIX FFS (Fast File System) [MJL+84]. As alteraes realizadas se relacionam com a utilizao do espao em disco, com o objetivo de melhorar o desempenho do sistema de arquivos. As principais mudanas so: no UNIX FFS, os ns-i no esto concentrados no incio do disco. O sistema divide o disco em regies de cilindros adjacentes, denominadas grupos de cilindros. Cada grupo de cilindro possui sua regio de n-i e sua regio de dados. Assim, mesmo em discos grandes, os ns-i esto mais prximos da regio de dados; o UNIX FFS permite a existncia de at dois tamanhos de bloco, iniciando com o tamanho mnimo de 4096 bytes, at o limite imposto pela controladora de disco, ou pelos drivers. A utilizao de blocos maiores reduz, em potencial, a quantidade de acessos a disco, mas aumenta a probabilidade de ocorrer um fenmeno denominado de fragmentao interna: freqentemente, o ltimo bloco de um arquivo no totalmente preenchido, provocando um desperdcio de espao. Para evitar a fragmentao interna, o UNIX FFS introduziu o conceito de fragmento de bloco, que ocupa apenas uma poro de um bloco do sistema de arquivos;
18
o gerenciamento do espao livre foi alterado, para tornar a alocao de blocos mais rpida. A lista de blocos livres foi substituda por um mapa de bits, que registra o estado de alocao de cada bloco e fragmento do disco. Como o mapa de bits pequeno, ele pode ser mantido na memria, dispensando acessos a disco durante a alocao de blocos; o UNIX FFS possui um novo algoritmo de alocao de blocos, que procura: alocar o n-i e os blocos de um arquivo no mesmo grupo de cilindros; alocar os blocos de um arquivo da forma mais contgua possvel e concentrar, sempre que houver espao, os arquivos de um mesmo diretrio em um nico grupo de cilindros. Dessa forma, o UNIX FFS consegue diminuir a quantidade de posicionamentos do brao, durante o processamento das requisies de acesso.
2.2.3 Armazenamento Estvel no UNIX

O sistema de arquivos do UNIX consegue prover armazenamento estvel atravs da gravao sncrona de dados. Na gravao sncrona, o sistema ativa o driver de disco, para iniciar imediatamente a transferncia do contedo alterado nos buffers da cache, para os blocos de disco apropriados. O processo de usurio requisitante da chamada de sistema bloqueado, at que a gravao termine. O sistema oferece duas maneiras de uma aplicao solicitar a gravao sncrona de dados. Primeiro, a aplicao pode informar ao sistema, no momento em que abrir o arquivo, que todas as operaes de escrita devem ser realizadas de forma sncrona. A aplicao faz essa opo, passando o parmetro O_SYNC na chamada de sistema open [AT89]. O sistema guarda essa informao na tabela de arquivos abertos, realizando a gravao sncrona dos dados de todas as requisies de escrita para esse arquivo. Quando uma operao de escrita retorna como bem-sucedida, o processo de usurio tem a certeza de que os dados foram realmente gravados no disco. Uma segunda forma de realizar a gravao sncrona invocando uma operao complementar, atravs da primitiva fsync, logo aps a operao de escrita no arquivo [Bac86]. A primitiva fsync bloqueia o processo do usurio, enquanto transfere para o disco o contedo de todos os buffers sujos da cache, com dados do arquivo informado. O processo de usurio s continua a sua execuo, quando a gravao dos dados termina. Existe, ainda, a primitiva sync, que transfere o contedo de todos os buffers sujos da cache para o disco. Porm, ela inadequada para implementar o armazenamento estvel de um arquivo: alm de gravar contedos do sistema de arquivos, que no se relacionam com o arquivo em questo, o processo de usurio no espera pelo final da operao. Assim, embora o sistema de arquivos dispare imediatamente a gravao dos buffers para disco, a aplicao no tem a garantia de que a operao ser concluda com sucesso.
Quando uma aplicao realiza muitas operaes de escrita, a espera pela gravao sncrona pode comprometer o seu desempenho. Portanto, nem sempre as aplicaes podem arcar com o custo do armazenamento estvel de dados, no sistema de arquivos do UNIX.
2.2.4 Procedimento de Recuperao do UNIX

Algumas circunstncias, como a falta de energia ou falhas no hardware, podem levar a um crash, deixando o sistema de arquivos num estado inconsistente. O comando fsck utilizado para investigar inconsistncias e reparar o sistema de arquivos [AT89]. Trata-se de um programa interativo, que utiliza a interface de caracter, ou de bloco, para ter acesso direto ao sistema de arquivos, sem valer-se das chamadas de sistema regulares [Bac86]. O fsck prev uma srie de possveis situaes de inconsistncia, resultantes da perda de memria voltil, como, por exemplo: blocos de dados referenciados por mais de um n-i; blocos de dados que no so referenciados; superbloco com informaes que no condizem com o estado real do sistema; lista de blocos livres corrompida; n-i com informaes invlidas; diretrios desconectados, ou com entradas incorretas. Para realizar tais verificaes, o fsck examina todos os metadados existentes no disco, incluindo todos os ns-i, blocos indiretos e diretrios, alm da lista de blocos livres. Pesquisando essas estruturas de dados e corrigindo as inconsistncias, o fsck consegue levar o sistema de arquivos a um estado consistente. Uma limitao desse procedimento de recuperao a necessidade de conferir, incondicionalmente, todos os metadados do sistema de arquivos, a despeito da quantidade de metadados inconsistentes [RO92]. Certas operaes, como a verificao de cada entrada de diretrio, podem requerer muitas leituras no-seqenciais, que exigem mltiplas operaes de posicionamento. No caso de discos grandes, com muitos arquivos, a leitura e o exame de todos os metadados, em geral, duram um longo tempo. Quanto maior a capacidade do disco, maior o tempo de execuo do procedimento de recuperao. Normalmente, apenas um pequeno nmero de metadados est sendo atualizado e pode tornar-se inconsistente, no momento de um crash. Se o procedimento de recuperao pudesse identificar as estruturas afetadas pelo crash, haveria a possibilidade de restaurar a consistncia do sistema de arquivos mais rapidamente. Outra limitao do procedimento de recuperao do UNIX o confinamento das aes corretivas aos metadados do sistema de arquivos. O fsck restringe-se a corrigir os valores dos metadados, para que voltem a corresponder ao estado real do sistema de arquivos, armazenado em disco. Esse procedimento incapaz de recuperar os blocos de dados que estavam armazenados na cache. Por isso, as aplicaes podem perder as ltimas atualizaes realizadas.
20
2.3 Tcnicas de Otimizao do Desempenho

Ao longo das ltimas dcadas, muitas tcnicas de otimizao do desempenho de sistema de arquivos foram desenvolvidas. Algumas transferem dados para a memria principal, visando reduzir a quantidade de acessos a disco, realizados para atender s requisies de aplicaes. Outras procuram utilizar os discos de forma mais eficiente, para diminuir o tempo de acesso. A maioria dos sistemas de arquivos atuais adota algumas dessas tcnicas, que sero descritas a seguir.
2.3.1 Tcnicas que Utilizam Memria Principal

As tcnicas de otimizao de sistemas de arquivos, que se fundamentam na utilizao da memria principal, procuram satisfazer s requisies de armazenamento, sem ler dados dos discos. A justificativa para o uso da memria principal no atendimento das requisies a grande diferena entre o tempo de acesso memria, na ordem de nanossegundos, e o tempo de acesso a disco, na ordem de milissegundos.
2.3.1.1 Caching de Leitura

Explorando a observao de que se um dado referenciado, existe uma alta probabilidade de que seja referenciado novamente, num futuro prximo [Sat93], a maioria dos sistemas de arquivos implementa algum tipo de caching, com o objetivo de aprimorar o desempenho. A cache uma rea de memria onde o sistema mantm os dados utilizados com maior freqncia. Alm dos dados de arquivos, os metadados e os diretrios tambm podem ser armazenados em cache. A caching de leitura contribui para a melhoria do desempenho, porque possibilita que muitas requisies de leitura das aplicaes sejam atendidas com uma cpia do dado na cache, sem a realizao de acesso a disco. O sistema de arquivos do UNIX faz uso ostensivo de caching de leitura. Quanto maior a quantidade de memria utilizada para caching, menor o nmero de acessos a disco realizados pelo sistema de arquivos. No entanto, o aumento demasiado da rea de memria dedicada cache prejudicial ao sistema operacional, porque a rea de memria da cache no pode ser utilizada para satisfazer outras demandas do sistema. O sistema operacional Sprite [OCD+88] implementa cache de tamanho varivel. Nesse sistema, o mecanismo de memria virtual negocia continuamente o espao de memria com o mecanismo de caching [NWO88].
21
2.3.1.2 Leitura Antecipada

A leitura antecipada de dados consiste em transferir para a memria principal os dados que a aplicao pode referenciar no futuro. O sistema precisa prever os dados que sero solicitados e ler antecipadamente esses dados do disco. Se a previso se confirmar, as aplicaes no precisaro esperar por acesso a disco. Apostando na probabilidade de que, quando um arquivo aberto, ele normalmente lido por inteiro [Sat93], o sistema de arquivos do UNIX monitora os acessos a um arquivo. Ao detectar acessos a blocos adjacentes de um arquivo, o sistema assume a ocorrncia de acesso seqencial e realiza a leitura antecipada. Essa tcnica bastante eficiente, pois grande parte dos acessos realizados seqencial [BHK+91].
2.3.1.3 Caching de Escrita

Na caching de escrita, a memria principal utilizada para melhorar o desempenho das operaes de escrita. No processamento de uma requisio de escrita, o sistema altera os dados na cache e retorna o controle para a aplicao, antes que os dados alterados sejam transferidos para o disco. Assim, a aplicao pode dar continuidade ao seu processamento mais rapidamente, melhorando o seu desempenho individual. A caching de escrita tambm otimiza o desempenho global de um sistema de arquivos, pois reduz a quantidade de dados transferidos para o disco. Enquanto um bloco permanece na cache, vrias operaes de escrita sobre esse bloco podem ser combinadas e transferidas para o disco, numa nica operao de sada. Alm disso, arquivos inteiros podem ser apagados enquanto esto na cache, diminuindo a quantidade de operaes de sada necessrias para atualizar o sistema de arquivos em disco. No obstante o benefcio do desempenho, a caching de escrita reduz a confiabilidade do sistema, porque a memria principal, utilizada na maioria dos computadores, no um meio confivel para o armazenamento de dados, por ser voltil [Tan95:146]. Por isso, a caching de escrita abre uma janela de vulnerabilidade no sistema: entre a modificao de um dado e a sua propagao para o disco. Ocorrendo um crash nesse intervalo, uma aplicao pode perder modificaes realizadas. Em resposta, os sistemas de arquivos restringem a utilizao da caching de escrita: o UNIX original limita em trinta segundos o tempo de permanncia de um bloco na cache; o UNIX FFS no permite a caching de escrita de estruturas fundamentais para a recuperao do sistema, como os diretrios e os ns-i.
22
2.3.2 Tcnicas de Otimizao de Disco

Essas tcnicas exploram as caractersticas dos discos magnticos, para ler e gravar dados armazenados em disco, com maior eficincia. O principal objetivo abreviar o tempo de espera das aplicaes que realizam acessos a disco. Uma requisio de acesso a disco especifica o cilindro, a cabea de leitura/gravao, o setor inicial e o nmero de setores que devem ser transferidos. Existem trs componentes que influenciam no tempo de acesso a disco: tempo de posicionamento, que o tempo necessrio para que o brao seja posicionado no cilindro correto; a latncia rotacional, que o tempo gasto no movimento de rotao, que posiciona o setor inicial sob a cabea de leitura/gravao, e o tempo de transferncia, que o tempo gasto lendo, ou gravando dados nos setores. Nos discos atuais, o tempo de posicionamento ainda o maior componente do tempo total do processamento de requisies de acesso. Por isso, as tcnicas de otimizao visam diminuir a quantidade de posicionamentos, seja atravs de uma nova organizao do disco, utilizando tcnicas mais otimizadas de alocao do espao em disco, seja atravs do escalonamento das requisies de acesso, ou mesmo implementando mais um nvel de cache dos dados armazenados no disco.
2.3.2.1 Caching de Trilha

A caching de trilha implementada por alguns drivers de disco, que mantm as trilhas mais recentemente utilizadas em buffers [Tan92]. Assim, as requisies envolvendo setores presentes na cache no precisam realizar transferncia de/para o disco. Durante o processamento de uma requisio, aps o posicionamento do brao, o driver fica livre durante a transferncia de dados. O driver pode aproveitar para ler uma trilha inteira no tempo correspondente a uma rotao. Para isso, a controladora deve ser dotada de um sensor, que permita ao driver identificar o setor sob a cabea de leitura/gravao e enviar uma requisio para o prximo setor. A caching de trilha implementada pelo driver de disco apresenta a seguinte desvantagem: o processador o responsvel pela transferncia de dados entre a cache e a rea de memria do programa de usurio. Algumas controladoras implementam a caching de trilha em sua prpria memria interna, de modo que a transferncia de dados pode ser realizada pelo hardware de acesso direto memria, sem ocupar o processador.
23
2.3.2.2 Tcnicas de Alocao

Os algoritmos de alocao visam arrumar os dados no disco, de forma a minimizar os posicionamentos necessrios para atender s requisies de acesso. Na tcnica de alocao contgua, o sistema armazena os dados de um arquivo em setores consecutivos, para que os acessos seqenciais sejam realizados sem a ocorrncia de posicionamentos entre os blocos. A alocao contgua favorece o desempenho de aplicaes que realizam acessos seqenciais a grandes arquivos. No entanto, no vantajosa para aplicaes que manipulam pequenos arquivos, ou que realizam muitos acessos randmicos aos grandes arquivos. Essa tcnica apresenta, ainda, a desvantagem de provocar o fenmeno da fragmentao externa: em ambientes com a criao e remoo freqente de arquivos, de tamanhos diferentes, a alocao contgua gera o aparecimento de espaos desperdiados no disco, difceis de ser reutilizados. O mtodo de gerenciamento do espao livre, do sistema de arquivos original do UNIX, no favorece a implementao da alocao contgua. Os blocos so alocados a partir de uma lista de blocos livres. Logo aps a criao de um sistema de arquivos, a lista de blocos livres est ordenada pelo nmero de bloco. Os arquivos so armazenados em posies contguas, porque os blocos so alocados na ordem em que aparecem na lista. medida que os blocos do disco vo sendo alocados e liberados, o espao em disco torna-se fragmentado e os blocos passam a aparecer na lista numa ordem aleatria, tornando a alocao contgua impossvel. Por isso, os acessos seqenciais apresentam um desempenho tipicamente ruim, nesse sistema. No UNIX FFS, a utilizao de um mapa de bits facilita a alocao de regies contguas de blocos livres. O algoritmo de alocao tenta armazenar os dados de um arquivo em blocos contguos, tanto quanto possvel, melhorando o desempenho dos acessos seqenciais. O agrupamento uma outra tcnica de alocao, que tambm utilizada para aumentar o desempenho das operaes de acesso a disco. O sistema de arquivos armazena os arquivos que so normalmente requisitados juntos, em posies prximas do disco. Assim, as requisies de acesso no provocam muitos posicionamentos. Por exemplo, o Unix FFS utiliza a alocao por agrupamento quando procura armazenar os arquivos de um mesmo diretrio num nico grupo de cilindros. Essa tcnica favorvel apenas em ambientes onde os acessos a arquivos so previsveis. No entanto, num sistema de arquivos de propsito geral, existem aplicaes de naturezas diversas, com comportamentos bastante variados, existindo, inclusive, aplicaes que mudam suas tendncias de acesso ao longo do tempo.
24
2.3.2.3 Tcnicas de Escalonamento

Quando uma requisio de acesso a disco est sendo atendida, as outras requisies que chegam so enfileiradas. O driver de disco faz o escalonamento da fila de pedidos pendentes, ou seja, determina a ordem em que as requisies sero processadas. Esse escalonamento pode ser realizado de forma a diminuir o tempo de posicionamento e aumentar o desempenho do sistema. Por exemplo, se um conjunto de requisies alterna entre uma trilha inicial e uma trilha do final do disco, o driver pode reordenar tais requisies, processando primeiro todas que fazem acesso trilha inicial e, a seguir, aquelas relacionadas com a trilha do final do disco. Vrios algoritmos de escalonamento foram propostos, conseguindo aumentar a eficincia dos discos em vinte e cinco por cento, no mximo [SCO90]. O algoritmo do menor posicionamento primeiro atende sempre requisio que precisar do menor deslocamento do brao, reduzindo o tempo de posicionamento. No entanto, quando o volume de requisies muito grande, esse algoritmo tende a manter o brao no meio do disco, prejudicando as requisies em qualquer dos extremos. O algoritmo do elevador no prioriza um conjunto de requisies, em detrimento de outras. O driver move o brao do disco sempre em uma determinada direo, at que no existam requisies pendentes nessa direo. Ento, o brao muda de direo. Esse algoritmo garante que, dado um conjunto qualquer de pedidos, o limite mximo de movimentao do brao do disco fixo e igual a duas vezes o nmero de cilindros a serem percorridos [Tan92]. As tcnicas de escalonamento contribuem para melhorar o desempenho de um sistema de arquivos apenas quando o fluxo de requisies de entrada/sada grande o suficiente para que existam filas de pedidos pendentes. Caso contrrio, o driver de disco atende de imediato toda requisio que chega.
2.4 Sistema de Arquivos em Rede

O NFS (Network File System) [SGK+85] um Sistema de Arquivos em Rede, que tem a flexibilidade de suportar sistemas heterogneos: permite a existncia de clientes baseados em arquiteturas variadas, como processadores Intel, RISC, Motorola, alm de permitir a interao de clientes utilizando sistemas operacionais diferentes, como clientes Macintosh, Windows, OS/2, Windows NT e vrios tipos de UNIX. O NFS possibilita que vrios sistemas de arquivos centralizados possam compartilhar dados, atravs de um mecanismo de montagem: cada servidor exporta um ou mais de seus diretrios; um cliente monta um diretrio exportado por um servidor no seu sistema de arquivos local, passando a ter acesso a toda a sub-rvore enraizada por este diretrio.
25
O NFS vastamente utilizado em ambientes distribudos, para possibilitar o compartilhamento de arquivos entre sistemas UNIX. Utilizando as operaes de montagem, cada usurio pode criar uma hierarquia de nomes customizada. Assim, cada cliente NFS pode ter uma viso diferente da rvore de diretrios. A Figura 2.5 mostra rvores de clientes NFS: cada cliente pode importar e montar, em qualquer ponto de sua rvore local, diretrios que foram exportados pelos servidores. Dois clientes podem formar rvores bem diferentes.
/
jogos doc bin
/
doc serv
/
etc
trab
prova
trab
prova
trab
jogos
prova
SERVIDOR
CLIENTE 1
CLIENTE 2
Figura 2.5: Vises do sistema de arquivos nos clientes NFS.
O NFS um sistema sem informaes de estado. Para esse tipo de sistema mais fcil permanecer em operao aps uma falta. Cada requisio do cliente contm todas as informaes necessrias ao seu atendimento pelo servidor. Por outro lado, grandes mensagens trafegam pela rede, podendo comprometer o desempenho.
2.4.1 Arquitetura do NFS

O NFS foi projetado como um servio de rede, que permite o compartilhamento de arquivos entre mquinas com sistemas de arquivos independentes, de forma transparente. O compartilhamento baseado no relacionamento cliente-servidor, utilizando chamada remota a procedimento (RPC) para a troca de solicitaes e respostas. Qualquer mquina pode ser um cliente ou um servidor. Para tornar um diretrio remoto acessvel, um cliente deve mont-lo em sua hierarquia local de arquivos. A partir desse momento, o cliente usa as mesmas chamadas para referenciar arquivos locais e remotos.
26
O sistema possui dois protocolos: o Protocolo de Montagem, com a funo de permitir que os servidores exportem diretrios e que os clientes os montem em seu sistema de arquivos local, e o Protocolo NFS, para realizao de operaes sobre arquivos remotos. O NFS est organizado em trs nveis, descritos a seguir, e exibidos na Figura 2.6. Nvel de Chamadas de Sistema. Verifica a sintaxe da chamada e valida parmetros, como o descritor de arquivo. Nvel VFS (Virtual File System). Distingue um arquivo local de um arquivo remoto. Para isso, verifica uma tabela com entrada uma para cada arquivo aberto, mantida pelo ncleo, contendo um identificador nico do arquivo em toda a rede, chamado de n-v (n virtual). Quando o arquivo local, o n-v aponta para um n-i do sistema de arquivos local. O VFS, ento, ativa procedimentos especficos desse sistema de arquivos para tratar a requisio. Quando o arquivo remoto, o n-v correspondente aponta para uma entrada na tabela de ns-r (ns remotos), no nvel de Protocolo NFS. Neste caso, o VFS ativa o citado nvel para realizar as requisies remotas. Nvel de Protocolo NFS. responsvel por realizar as chamadas remotas a procedimento para o nvel de Protocolo NFS do servidor apropriado a atender a uma requisio de arquivo remoto. Ele possui uma tabela com um n-r para cada arquivo remoto aberto. Em um n-r esto as informaes necessrias para o acesso ao arquivo, como o endereo do servidor e a autorizao de manipulao do arquivo.
CLIENTE
CHAMADAS DE SISTEMA
SERVIDOR
INTERFACE VFS INTERFACE VFS
SISTEMA DE ARQUIVOS LOCAL UNIX
OUTRO SISTEMA DE ARQUIVOS
CLIENTE NFS
SERVIDOR NFS
SISTEMA DE ARQUIVOS LOCAL UNIX
RPC/XDR
RPC/XDR
DISCO REDE
DISCO
Figura 2.6: Arquitetura do NFS.

2.4.2 Localizao de Arquivos no NFS

Quando um cliente deseja ter acesso a um arquivo (ou diretrio) remoto, ele faz uma chamada de sistema comum para o ncleo, que analisa o nome de caminho e verifica que o arquivo remoto, com base nas informaes da tabela de montagem. A seguir, o ncleo procura uma entrada para o arquivo na tabela de ns-v, do VFS. Caso ainda no exista, passa o controle para o cliente NFS, que requisita acesso ao arquivo, atravs de uma RPC enviada ao servidor. No servidor, o nvel de Protocolo NFS repassa a requisio ao nvel VFS, que encontra o arquivo no disco do servidor. Uma resposta enviada ao cliente. O Protocolo NFS do cliente cria um n-r para o arquivo em suas tabelas e passa as informaes recebidas para o VFS. Este acrescenta um n-v em suas tabelas, apontando para o n-r do cliente NFS. A traduo de um nome de caminho realizado quebrando o mesmo em seus diretrios componentes. A seqncia de passos descrita no pargrafo anterior repetida para cada diretrio remoto do nome de caminho, at chegar ao arquivo desejado, quando o processo cliente recebe um descritor de arquivo, que serve de ndice para a tabela de ns-v. O ncleo do cliente sabe quando um ponto de montagem atravessado, atravs das informaes da tabela de montagem. O NFS permite a montagem em cascata, ou seja, montar um sistema de arquivos remoto no topo de outro sistema de arquivos remoto j montado. Um servidor, entretanto, no pode agir como um intermedirio entre um cliente e outro servidor. Durante a localizao de um arquivo, o cliente deve estabelecer uma conexo cliente-servidor em separado, com cada servidor que armazena diretrios componentes do nome de caminho. Para agilizar a localizao de arquivos, os clientes podem manter caches de diretrios, com os ns-v dos diretrios remotos. Assim, arquivos com o mesmo nome de caminho inicial podem ser localizados mais rapidamente.
2.4.3 Caching no NFS

O NFS realiza caching tanto no cliente, quanto no servidor. Em geral, o sistema transfere grandes blocos de dados para a cache (tipicamente de 8KB), explorando a observao de que quando um arquivo aberto, ele normalmente lido por inteiro [Sat93]. Por isso, comum o uso de leitura antecipada de blocos do arquivo para a cache de cliente, com o objetivo de otimizar as operaes de leitura seqencial de arquivos. O NFS utiliza a poltica de propagao retardada, associando um temporizador a cada bloco de cache. Quando ele expira, o bloco correspondente enviado de volta ao servidor. Esse tempo , em geral, de trs segundos para diretrios e de trinta segundos para arquivos.
Essa poltica de atualizao de cache de cliente torna a semntica de compartilhamento do NFS confusa e dependente de temporizaes: um novo arquivo pode demorar trinta segundos para tornar-se visvel aos demais clientes do sistema. No NFS, um cliente faz a validao dos dados armazenados em sua cache no momento em que o arquivo aberto. Essa estratgia apresenta um problema em potencial: se um determinado cliente A abre um arquivo para leitura, copiando o mesmo para a sua cache e, a seguir, o cliente B abre o mesmo arquivo para escrita, as alteraes do arquivo realizadas por B no invalidam a cpia de A, pois A no tentar abrir o arquivo novamente. Para solucionar esse problema, os fornecedores do NFS oferecem um mecanismo opcional de bloqueio de arquivos. O sistema NFS implementa apenas caching de leitura nos servidores, gravando diretamente em disco os dados das operaes de escrita [Ste91] (note que o NFS implementa caching no cliente, tanto para operaes de leitura, quanto para operaes de escrita). Uma aplicao que requer armazenamento estvel dos dados, ela no pode se beneficiar com a cache de cliente, nem com a cache de servidor. Ao trmino de uma operao de escrita, o sistema precisa garantir de que os dados foram efetivamente gravados no disco do servidor. Os principais Sistemas de Arquivos Distribudos do mercado no oferecem esse tipo de servio. Tanto no UNIX quanto no NFS, o cliente precisa invocar explicitamente uma operao flush, para obrigar que os dados em buffer sejam gravados em disco. A aplicao espera pelo final da transferncia dos dados para disco. Por isso, o ambiente NFS tambm requer um Servio de Armazenamento Estvel mais eficiente.
2.5 Concluses
O contedo descrito neste captulo evidencia cinco pontos importantes, que devem ser considerados na elaborao do projeto de um servio de armazenamento estvel. Primeiro, tanto um sistema de arquivos tradicional, como o UNIX, quanto um sistema de arquivos em rede, como o NFS, oferecem a gravao sncrona como mtodo de prover estabilidade no armazenamento de dados. Segundo, a gravao sncrona apresenta um alto custo de desempenho. Terceiro, as tcnicas de otimizao baseadas em memria conseguem aprimorar o desempenho, mas diminuem a confiabilidade do sistema. Quarto, as tcnicas de otimizao de disco no conseguem melhorar significativamente o desempenho dos sistemas de arquivos de propsito geral. Quinto, com o advento dos sistemas distribudos, surgiram novas facilidades de comunicao, possibilitando a interao de processos executados em mquinas diferentes.
29
Captulo 3
3 Evoluo Tecnolgica e o Novo Desafio
Este captulo apresenta a motivao para novas pesquisas em tcnicas de armazenamento estvel de dados. O argumento bsico que o mtodo de armazenamento estvel adotado nos sistemas de arquivos tradicionais inadequado para a tecnologia atual. Mais especificamente, o armazenamento estvel de dados, baseado na gravao sncrona em disco, um entrave, cada vez maior, ao desempenho de muitas aplicaes, devido s tendncias da tecnologia corrente. Enquanto estiverem aguardando o processamento das requisies de armazenamento, as aplicaes no sero capazes de explorar plenamente as melhorias tecnolgicas, tais como: processadores, memrias e redes mais velozes. As necessidades de armazenamento das novas aplicaes exigem que os sistemas de arquivos sejam mais eficientes no atendimento aos requisitos de desempenho e confiabilidade. No entanto, as tendncias da tecnologia atual colocam os sistemas de arquivos diante de um impasse entre esses dois requisitos. Basicamente, as tcnicas de otimizao de desempenho adotadas fundamentam-se no uso ostensivo da memria principal. Porm, a volatilidade da memria diminui a confiabilidade do sistema, pois leva ao risco de perda de dados. Assim, as aplicaes que necessitam gravar dados de forma estvel continuam pagando um alto custo de desempenho, para realizar a gravao sncrona dos dados em disco. Paralelamente, ocorrem avanos significativos na tecnologia de redes: as altas taxas de transferncia, disponveis atualmente, representam um recurso em potencial, a ser utilizado nas tcnicas de otimizao de sistemas de arquivos. A tcnica de armazenamento estvel descrita nesta dissertao considera essa e as demais tendncias da tecnologia, assim como as necessidades de armazenamento das aplicaes. O servio proposto no requer tecnologia de hardware especial, nem alteraes no comportamento das aplicaes: possibilita que o sistema de arquivos utilize as mudanas tecnolgicas de modo favorvel.
Captulo 3 Evoluo Tecnolgica e o Novo Desafio 30
3.1 Tecnologia para Sistemas de Arquivos

Os principais componentes de hardware integrantes de um sistema de arquivos so: processador, disco e memria principal. Adicionalmente, um sistema de arquivos distribudo necessita de uma estrutura de rede, para viabilizar a comunicao entre clientes e servidores. Esta seo examina como a tecnologia desses componentes est mudando. Todos os componentes de hardware citados esto em constante evoluo, beneficiando os sistemas de arquivos, especialmente no que se refere capacidade de armazenamento e ao desempenho. Porm, para que os sistemas de arquivos possam usufruir plenamente dos avanos da tecnologia, preciso que o projeto desses sistemas seja capaz de lidar com um aspecto importante do progresso tecnolgico: ele no acontece no mesmo ritmo para todos os componentes.
3.1.1 Tecnologia de Processador

Os avanos na tecnologia de semicondutores permitiram uma grande evoluo na tecnologia de processador. Na ltima dcada, a velocidade dos processadores cresceu cerca de cinqenta por cento ao ano [Mud+96] [Int97]. Considerando sistemas SPP (Scalable Parallel Processors), que podem ser configurados com centenas, ou mesmo milhares de processadores em paralelo, o poder de processamento tornou-se quinhentas vezes maior nesse perodo [MCP+98]. O grande aumento na capacidade de processamento pressiona os outros elementos de hardware dos sistemas computacionais a tornarem-se mais velozes, para que o sistema permanea o mais balanceado possvel. A tecnologia de processador importante para um sistema de arquivos, porque, quanto maior o poder de processamento, melhor ser o desempenho do sistema. Infelizmente, porm, o desempenho de um sistema no cresce na mesma proporo que a velocidade dos processadores, pois depende, tambm, de outros componentes de hardware. Particularmente, o desempenho de um sistema de arquivos est intrinsecamente subordinado tecnologia de disco. Por exemplo, assumindo, hipoteticamente, que a tecnologia de disco permanece esttica e considerando uma aplicao que realiza um acesso a disco a cada cem milissegundos de tempo de processador e leva quinhentos segundos para executar no seguinte sistema: constitudo por uma CPU (Unidade Central de Processamento) de um MIPS (Milhes de Instrues Por Segundo) e um disco, cujo tempo mdio de acesso de dez milissegundos. Substituindo a CPU por outra de cem MIPS, a aplicao ir finalizar em 94,2 segundos. Assim, a aplicao melhora seu desempenho em apenas 5,3 vezes, mesmo com uma CPU cem vezes mais rpida.
Captulo 3 Evoluo Tecnolgica e o Novo Desafio
31
O exemplo ilustra o conceito conhecido como Lei de Amdahl [Amd67]: se parte de um sistema torna-se mais veloz e a outra parte no, ento o desempenho total ser prejudicado pela parte no melhorada. Na tecnologia atual, a parte que mais evolui so os processadores, enquanto os discos constituem a parte que no progride no mesmo ritmo. Na poca, Amdahl previu que grandes aumentos na velocidade de processadores resultariam apenas em pequenas melhorias no desempenho global do sistema, a no ser que fossem acompanhadas por avanos correspondentes na tecnologia de armazenamento secundrio.
3.1.2 Tecnologia de Disco

Os discos magnticos ainda constituem o principal meio de armazenamento no-voltil de dados, nos sistemas de arquivos atuais. A evoluo da tecnologia de disco tambm contribui para a melhoria dos sistemas de arquivos. Contudo, os avanos dessa tecnologia concentram-se mais nas reas de custo e capacidade, do que no desempenho. Na ltima dcada, a capacidade de armazenamento dos discos magnticos cresceu cerca de vinte e sete por cento ao ano [CLG+94], enquanto o desempenho no evoluiu no mesmo ritmo. Existem dois componentes bsicos, que devem ser considerados na avaliao do desempenho de um disco: o tempo de transferncia e o tempo de acesso. O tempo de transferncia a medida da rapidez na qual os dados so transferidos de/para o disco. Essa medida importante para as requisies que armazenam grandes quantidades de dados, nas quais a maior parte do tempo de processamento gasta com a transferncia de dados. Os valores apresentados em [CLG+94] demonstram que a taxa de transferncia dos discos magnticos cresce, aproximadamente, vinte e dois por cento ao ano. O tempo de acesso o tempo que uma requisio individual de armazenamento leva para finalizar: o somatrio do tempo de posicionamento, do tempo de latncia rotacional e do tempo de transferncia de dados. O tempo de acesso a disco vem evoluindo em propores bem menores que a velocidade dos processadores: enquanto o poder de processamento aumenta cerca de cinqenta por cento ao ano, a tecnologia de disco precisou de uma dcada para reduzir o tempo de acesso, nessa mesma proporo [CLG+94]. O tempo de acesso a disco influencia no desempenho de toda aplicao que grava dados de forma sncrona, ou seja, que precisa esperar pelo trmino de cada requisio de sada antes de prosseguir. Assim, o tempo de acesso a disco crucial para o armazenamento estvel de dados nos sistemas de arquivos tradicionais. O tempo de posicionamento e o tempo de latncia dos discos so difceis de aprimorar, porque dependem de movimentos mecnicos. Por isso, os projetos que objetivam o aumento do desempenho dos discos se concentram na melhoria do tempo de transferncia, como a tecnologia RAID, descrita a seguir.
3.1.2.1 Tecnologia RAID

O tempo de transferncia das operaes de acesso a disco pode ser melhorado com a utilizao da tecnologia RAID - Redundant Array of Inexpensive Disks [CLG+94]. RAID um mtodo de armazenamento proposto para simular um disco de alta capacidade, explorando o paralelismo de um conjunto de discos independentes. Os dados de uma requisio de escrita so segmentados e espalhados em mltiplos discos. A intercalao de partes de dados prov um alto desempenho, pois permite que vrias operaes de entrada/sada sejam realizadas paralelamente. Existem dois aspectos nesse paralelismo. Primeiro, vrias requisies podem ser atendidas ao mesmo tempo, por discos diferentes. Por exemplo, se um arquivo espalhado em cem discos, ento o sistema pode processar, simultaneamente, at cem requisies de entrada/sada, envolvendo partes diferentes do arquivo e atingindo, desse modo, um desempenho bem superior a um nico disco. Segundo, uma mesma requisio, envolvendo mltiplos blocos de um arquivo, pode ser atendida por vrios discos, operando de forma coordenada. Para explorar o benefcio de alto desempenho provido pela tecnologia RAID, os sistemas de arquivos devem arrumar os dados nos discos, de modo que as requisies possam utilizar vrios discos, de forma concorrente. Caso contrrio, o RAID no ser mais veloz do que um nico disco. Quanto maior a quantidade de discos utilizados no RAID, maior o potencial para proporcionar melhorias no desempenho. Por outro lado, um grande nmero de discos diminui a confiabilidade do sistema. Para solucionar esse problema, a tecnologia RAID emprega redundncia, na forma de cdigos de correo de erro. Infelizmente, a redundncia influencia negativamente no desempenho, pois toda operao de escrita precisa atualizar a informao redundante. Para amenizar o prejuzo no desempenho, os sistemas utilizam memria adicional para realizar caching dos dados necessrios para o clculo da informao redundante. Existem vrias organizaes de RAID que oferecem diferentes nveis de desempenho, de confiabilidade e de relao custo/benefcio. Elas diferem em dois aspectos principais: o tamanho dos dados intercalados e a tcnica utilizada para implementar a redundncia. Alguns esquemas de RAID intercalam pequenas unidades de dados, como o RAID Nvel 3, que espalha os bits de cada palavra em diferentes discos. Nesse tipo de esquema, toda requisio de entrada/sada, independentemente do seu tamanho, faz acesso a todos os discos do RAID, resultando em altas taxas de transferncia para todas as requisies. Porm, somente uma requisio pode ser atendida de cada vez. Outros esquemas de RAID, como RAID Nveis 4, 5 e 6, intercalam blocos inteiros de dados. Assim, pequenas requisies fazem acesso somente a um nmero reduzido de discos, possibilitando que vrias requisies sejam atendidas ao mesmo tempo.
Existem diversas tcnicas para a implementao de redundncia, que variam quanto ao mtodo utilizado para calcular e distribuir a informao redundante atravs do RAID. Embora alguns esquemas de RAID faam uso da codificao de Reed-Solomon ou Hamming, a maioria utiliza paridade. Alguns esquemas de RAID concentram a informao redundante num pequeno nmero de discos, enquanto outros distribuem a informao redundante uniformemente, atravs de todos os discos. A Figura 3.1 exibe um exemplo tpico de RAID Nvel 4. Os dados so segmentados em blocos e espalhados em quatro discos. Um quinto disco armazena os blocos de paridade (P1, P2, ...) contendo os valores calculados atravs da operao XOR (OU-exclusivo) dos blocos correspondentes nos discos de dados. Por exemplo, caba byte em P1 o XOR dos bytes correspondentes nos blocos B1, B2, B3 e B4. Se um disco falhar, sua informao pode ser restaurada, mediante uma simples operao XOR dos blocos de paridade com os blocos de dados correlatos dos outros discos. No exemplo apresentado, a redundncia de apenas vinte e cinco por cento. O espelhamento de disco o RAID Nvel 1, uma forma mais simples de RAID, com redundncia de cem por cento, ou seja, o nmero de discos dobrado [McK96]. O sistema de arquivos do NetWare [MMP94], do Windows NT [Cus94] e de outros realiza espelhamento de discos.
CONTROLADORA RAID
B1 B5
B2 B6
B3 B7
B4 B8
P1 P2
Figura 3.1: Exemplo de RAID Nvel 4. Apesar das melhorias do tempo de transferncia propiciadas pelo uso de RAID, o desempenho de um disco magntico afetado por outros componentes do tempo de acesso, que no possuem muitas opes de otimizao.
3.1.2.2 Tecnologia de Armazenamento tico

Alm da tecnologia RAID, que conseguem prover um melhor desempenho do que a tecnologia de disco magntico convencional, existe uma tecnologia de armazenamento tico, capaz de prover alta densidade de armazenamento e maior integridade de dados. Mais propriamente, existem duas tecnologias de armazenamento tico, cada uma com diferentes caractersticas e algumas aplicaes distintas: a tecnologia de CD-ROM e a tecnologia magneto-tica. Nenhuma delas representa uma alternativa vivel para a substituio do armazenamento magntico convencional, no o uso generalizado e cotidiano, mas cada uma possui a sua aplicabilidade, para o armazenamento secundrio de informaes [Nor95]. A operao de todos os dispositivos de armazenamento tico depende da tecnologia laser. O raio laser um feixe de luz altamente controlado e concentrado, utilizado, neste caso, para gravar dados em meios ticos especiais, para permitir a gravao magntica tradicional em material magneto-tico especial, ou para ler dados previamente gravados. Na tecnologia de CD-ROM, os discos so constitudos por uma lmina de plstico rgido e recobertos por uma pelcula protetora. A gravao realizada atravs de laser de baixa intensidade, que queima pontinhos correspondentes a 1 na superfcie. A vantagem desse dispositivo a capacidade de armazenar uma grande quantidade de informaes de forma confivel. A confiabilidade do CD-ROM deve-se aos seguintes fatores: constitudo de material altamente resistente e durvel; a superfcie do disco selada em seu revestimento plstico, sendo tocada apenas pela luz; o cabeote de leitura/gravao opera duas mil vezes mais afastado da superfcie do disco do que os cabeotes dos discos magnticos; grande espao do disco utilizado para gravar informaes de deteco e correo de erros; e finalmente, o laser no l a face exterior da superfcie do disco, sendo capaz de ignorar pequenos danos fsicos, como arranhes e sujeiras. Inicialmente, a tecnologia de CD-ROM estava limitada a um nico ciclo de gravao; atualmente, existem discos de CD-ROM regravveis. No entanto, esta nova capacidade restrita a alguns ciclos de gravao, no podendo ser utilizada indefinidamente, porque, de fato, as informaes no podem ser apagadas da superfcie do disco (as marcas feitas pelo laser so permanentes), sendo as novas gravaes realizadas mediante o aproveitamento do espao ainda disponvel no disco. A tecnologia de CD-ROM bastante utilizada para a realizao de cpias de segurana e para a distribuio de dados: atualmente, existe uma grande quantidade de softwares comercializados em CD-ROM.
As unidades magneto-ticas utilizam meios magnticos para armazenar informao por controle a laser. Essas unidades empregam cartuchos preenchidos com meios magnticos de leitura/gravao. Para gravar informaes, os discos utilizam as mudanas de polaridade no material magntico quando ele aquecido. Quando o laser aquece o material magntico do disco, torna-se fcil mudar a polaridade do material. Depois que o material esfria, a polaridade fixada dentro da nova orientao. A tecnologia MO oferece armazenamento de dados mais durvel do que a de discos magnticos e disquetes convencionais: os discos so feitos de plstico policarbonato de alta resistncia, semelhante ao material de vidros prova de balas; a camada de dados mantida em segurana entre um sanduche de policarbonato. Adicionalmente, os dados so imunes a campos magnticos, pois sua gravao tambm depende da tecnologia laser. As unidades magneto-ticas so utilizadas em aplicaes de arquivos off-line e, principalmente, para a realizao de cpias de segurana. Embora a tecnologia de armazenamento tico possa oferecer grandes densidades de armazenamento, com alta confiabilidade, seu desempenho ainda bastante inferior ao dos discos magnticos: o tempo mdio de acesso a um CD-ROM cerca de vinte vezes maior que maior que o tempo mdio de acesso a um disco magntico, enquanto uma unidade magneto-tica mais lentas tanto em transferncia, quanto em acesso de dados, do que uma unidade de disco magntico. Por isso, a tecnologia de disco magntico continua sendo o meio padro de armazenamento secundrio nos sistemas computacionais.
3.1.3 Tecnologia de Memria

Assim como a tecnologia de processador, a tecnologia de memria valeu-se das melhorias nos semicondutores, aprimorando tanto a capacidade de armazenamento, quanto a velocidade de acesso. Esses avanos englobam toda a hierarquia de memria principal dos computadores, incluindo os registros de processador e os vrios nveis de cache. A memria DRAM (Dynamic Random Access Memory) o padro de memria principal mais utilizado nos computadores atuais, devido ao seu custo cada vez menor, associado a velocidades de acesso e capacidades cada vez maiores. Na ltima dcada, a velocidade de acesso da memria DRAM cresceu aproximadamente dez por cento ao ano [Mud+96]. Embora essa taxa de crescimento seja inferior ao aumento da velocidade dos processadores, ela bem maior que o aumento da velocidade de acesso a disco. Por isso, praticamente, todos os sistemas de arquivos atuais utilizam a memria principal para implementar tcnicas de otimizao de desempenho, que minimizam o impacto negativo causado pela tecnologia de disco, tais como: leitura antecipada, caching de leitura e caching de escrita [Tan92].
36
Com a disponibilidade de grandes memrias principais, possvel implementar tcnicas agressivas de leitura antecipada, que reduzem o tempo mdio de espera das aplicaes. De forma similar, medida que as caches de arquivo aumentam, cresce tambm a frao de requisies de leitura que podem ser atendidas sem a necessidade de fazer acesso a disco, contribuindo positivamente para o desempenho das aplicaes. No caso de caching de escrita, a maior disponibilidade de memria principal no leva a ganhos substanciais no desempenho. O maior benefcio consiste no aumento da eficincia dos acessos a disco, porque permite que o sistema faa a reordenao de um nmero maior de requisies de escrita, quando existe uma fila de pedidos pendentes. No entanto, essa reordenao leva apenas a um aumento modesto do desempenho. O benefcio que a caching de escrita consegue prover ao desempenho de um sistema mais afetado pelo tempo que os dados permanecem na cache, do que pelo tamanho da cache. Quanto mais tempo os dados de escrita permanecem na cache, maior a chance de que sejam absorvidos (reescritos ou apagados). Entretanto, o aumento desse tempo tambm leva a um maior risco de perder dados. Portanto, existe uma limitao das caches de arquivo para reduzir o trfego de escrita em disco, que independe do tamanho da cache [BAD+92]. As aplicaes que precisam gravar dados de forma estvel no admitem qualquer risco de perder dados. Por isso, realizam a gravao sncrona dos dados, sem tirar proveito da caching de escrita. Assim, um sistema de arquivos tradicional no consegue utilizar a memria principal para melhorar o desempenho do armazenamento estvel de dados.
3.1.4 Tecnologia de Rede

A evoluo da tecnologia de rede beneficia tanto as redes locais, quanto as redes de longa distncia, com o aprimoramento da confiabilidade e das taxas de transmisso de dados. No incio desta dcada, a idia de taxas de transmisso de cem Mbps (megabits por segundo) em redes locais, at o usurio final e a preos acessveis, ainda era vislumbrada como um futuro distante. Hoje, essa taxa de transmisso uma realidade comum. As normas para cabeamento estruturado contriburam para a melhoria da qualidade das redes implementadas. Por exemplo, a norma TIA/EIA-568-A [TE95], que abrange, inclusive, a integrao de voz e dados, especifica: os requisitos mnimos para cabeamento de telecomunicaes dentro de edifcios comerciais; topologia e distncias recomendadas; meios de transmisso; designaes de conectores e pinos; critrios para teste de desempenho e a vida til dos sistemas de cabeamento (como sendo superior a dez anos). Atualmente, j esto padronizadas redes de alta velocidade, como Gigabit Ethernet [IEE98], ATM ou Myrinet [Boden. Apud ADN+95:41]. Essas redes oferecem taxas de transferncia cada vez mais altas: Gigabit Ethernet, a 1 Gbps e ATM OC24, a 1.2 Gbps.
37
A infra-estrutura de redes de alta velocidade permite a construo de sistemas distribudos capazes de realizar comunicao de alto desempenho. Essa facilidade pode ser utilizada nas tcnicas de otimizao de sistemas de arquivos. Por exemplo, a replicao de arquivos em vrias mquinas de um sistema distribudo uma tcnica utilizada para aumentar a disponibilidade e a confiabilidade do sistema [Tan95] [Sat93] [LS90]. Quando um sistema mantm cpias de arquivos em vrios servidores, a falta de alguns servidores no impede o acesso a um arquivo, a partir de uma cpia existente em um servidor em funcionamento. O sistema de arquivos precisa garantir a consistncia das rplicas, refletindo as modificaes de um arquivo em todas as cpias existentes. A atividade extra de propagar as atualizaes de arquivos, para todas as suas respectivas rplicas, provoca uma perda no desempenho, que minimizada quando os dados so transmitidos atravs de redes de alta velocidade. As redes de alta velocidade tambm representam um recurso estratgico para novas tcnicas de armazenamento estvel de dados. Estudos demonstraram que a latncia decorrente de um acesso atravs de uma rede de alta velocidade menor do que a latncia introduzida pela leitura de um bloco num disco local [Dah+94]. Baseado nesse fato, o SALIUS utiliza as redes de alta velocidade para replicar dados da cache de arquivos em vrias mquinas de um sistema distribudo, como forma de prover confiabilidade ao sistema de arquivos, eliminando a necessidade de realizar gravao sncrona de dados.
3.2 Demanda de Armazenamento das Aplicaes

Outro fator que influencia no projeto de um sistema de arquivos a demanda de armazenamento das aplicaes. Um sistema de arquivos deve ser preparado para atender s necessidades das aplicaes, considerando os tipos de requisies de armazenamento, a freqncia na qual elas acontecem e os requisitos que devem ser atendidos. As requisies podem ser classificadas em pequenas ou grandes, conforme a quantidade de dados armazenados e a tecnologia de disco utilizada. Uma requisio considerada pequena quando o tempo de acesso mais dominado pelo tempo de posicionamento e tempo de latncia, do que pelo tempo de transferncia de dados. As grandes requisies so aquelas onde o tempo de transferncia o maior componente do tempo total necessrio para o processamento da requisio. Como os avanos da tecnologia de discos magnticos, no campo do desempenho, concentram-se na melhoria do tempo de transferncia, as aplicaes com predominncia de grandes requisies de armazenamento so mais favorecidas do que aquelas que fazem pequenas requisies [RO92].
38
As requisies de armazenamento tambm podem ser classificadas em seqenciais e randmicas. Uma requisio seqencial provoca o acesso a um objeto numa ordem logicamente contgua, como, por exemplo, a leitura de um arquivo do incio ao fim. Qualquer requisio dita randmica, quando no seqencial. A tecnologia RAID beneficia mais as requisies seqenciais do que as randmicas, pois pequenos acessos seqenciais podem ser combinados num grande acesso seqencial, cujos dados podem ser gravados em mltiplos discos, paralelamente. Esse o caso, por exemplo, das aplicaes de supercomputadores, caracterizadas principalmente por acessos seqenciais a grandes arquivos. As requisies randmicas, pelo contrrio, normalmente sofrem maior influncia do tempo de latncia e do tempo de posicionamento dos discos. As aplicaes que realizam operaes de escrita com muita freqncia sofrem maior influncia da tecnologia de disco. Em ambientes de escritrio e engenharia, predominam aplicaes que atualizam dados com freqncia: o desenvolvimento de programas, a preparao de documentos, as simulaes e os projetos interativos. Na rea de suporte a deciso, de modo inverso, as aplicaes raramente modificam dados e prevalecem as operaes de leitura. Nesse caso, o desempenho pode ser otimizado com tcnicas que utilizam memria principal, como caching e leitura antecipada. As aplicaes diferem, ainda, quanto ao nvel de confiabilidade e de desempenho exigidos. Para algumas aplicaes, o desempenho um fator crtico, ao tempo em que admitem a perda eventual de uma pequena quantidade de dados. Por exemplo, no processamento de imagens, caracterizado pela exibio de seqncias de quadros, a perda eventual de alguns quadros no compromete o funcionamento da aplicao. Contudo, um atraso na exibio dos quadros pode chegar a invalidar a aplicao. Outras aplicaes, ao contrrio, exigem alta confiabilidade, no permitindo qualquer perda de dados. Um exemplo tpico um sistema de automao bancria, onde grande parte das operaes envolve valores monetrios, que precisam ser preservados. O desempenho tambm um requisito importante nessa aplicao, embora pequenos atrasos no processamento sejam tolerveis. Em geral, esse sistema caracteriza-se pelo processamento de transaes com muitas requisies de armazenamento, pequenas e randmicas, ou seja, aquelas cujo processamento individual no otimizado pela tecnologia RAID. No entanto, o paralelismo provido pelo uso de RAID possibilita o processamento concorrente de vrias transaes, melhorando o desempenho global do sistema. Como a confiabilidade um requisito fundamental, o sistema deve garantir a estabilidade dos dados armazenados. Portanto, a aplicao precisa realizar a gravao sncrona dos dados. Assim, mesmo com o auxlio de RAID, o desempenho prejudicado pelo tempo de acesso a disco.
39
3.3 Tendncias da Tecnologia

O crescimento acelerado do poder de processamento dos computadores tende a prosseguir, pelo menos, nos prximos dez anos [MCP+98]. A arquitetura de computadores propende para a explorao, cada vez maior, do paralelismo externo e do interno aos processadores. Atualmente, existem vrios sistemas SPP em funcionamento, com mais de cem processadores em paralelo, tais como: Sun NOW, na Universidade da Califrnia, em Berkeley [ACP95]; Tera MTA-1, no SDSC (San Diego Supercomputer Center) [ABC+97]; o HP Exemplar X-Class, conhecido como SPP 2000 [AD98] e o IBM SP Family [SSA+95]. A tecnologia de rede tambm tende a continuar evoluindo, aumentando progressivamente as taxas de transferncias, enquanto os custos se tornaro cada vez mais acessveis. As tecnologias emergentes, como Gigabit Ethernet e 1.2 Gbps ATM, ainda consideradas de alto custo, sero amplamente utilizadas, em aproximadamente cinco anos. As tecnologias de rede de alta velocidade possibilitam comunicao de alto desempenho entre os computadores. Existe, inclusive, uma tendncia em utiliz-las na construo de sistemas distribudos, fortemente acoplados, capazes de suportar tanto as aplicaes distribudas, quanto as aplicaes paralelas. Muitas pesquisas tm sido desenvolvidas, com o objetivo de prover comunicao de alto desempenho, tanto sobre redes ATM [ECG+92] [PLC95], quanto sobre redes Gigabit Ethernet [STH+99]. Como as melhorias na velocidade de acesso memria no acompanham o ritmo de evoluo dos processadores, a latncia de memria, em relao execuo de instrues, tende a crescer substancialmente [Mud+96]. Essa propenso, aliada utilizao cada vez maior de memrias fisicamente distribudas, est levando a memrias NUMA (Nonuniform Memory Access) [LEK91], com latncias que variam de poucos ciclos de processador, para dados em cache, at centenas ou milhares de ciclos. Para diminuir essa latncia, os projetos tendem a adotar vrios nveis de cache, procurando aprimorar os esquemas de coerncia de cache. Tambm existe a tendncia de incorporar instrues de reordenao e leitura antecipada, nos processadores de alto desempenho, e de adicionar inteligncia s placas de memria, para otimizao dos acessos. Adicionalmente, os sistemas tendem ao uso cada vez mais intenso de multithreading. Uma thread uma abstrao da computao, para denotar um grupo de instrues postas para executar como uma unidade. Decompondo o trabalho a ser executado em threads, os programas podem mascarar a latncia de memria, mantendo threads suspensas, enquanto o acesso a dados da memria estiver sendo realizado, e colocando threads para executar, quando os dados requisitados estiverem disponveis.
40
Diferente das tecnologias citadas anteriormente, que possuem muitas possibilidades de evoluo, a tecnologia de discos magnticos est fadada a tornar-se um entrave progressivamente maior ao desempenho dos sistemas. O tempo de acesso a disco depende de movimentos mecnicos, que so muito difceis de aprimorar [WZ94]. Portanto, existe uma tendncia de ampliao da discrepncia entre as velocidades de processador e de disco. Assim, se uma aplicao gera um grande nmero de pequenas transferncias para disco, separadas por posicionamentos, mesmo que conte com processadores muito rpidos, no alcanar um bom desempenho, devido ao atraso introduzido pelos acessos a disco. A adio de memria no-voltil na cache dos sistemas computacionais [BAD+92] uma das tendncias das novas arquiteturas de computadores, permitindo a utilizao de esquemas mais agressivos de caching de escrita. No entanto, sistemas com alta demanda de operaes escrita ainda precisaro de uma forma eficiente de enviar os dados alterados para o disco, quando as caches estiverem cheias. Alm disso, quanto mais tempo os dados armazenados permanecerem na cache, maior a chance de que sejam corrompidos, em funo de um erro de software. O armazenamento no-voltil de dados deve passar, ento, por mudanas radicais, para permitir o surgimento de sistemas mais balanceados, com velocidades crescentes. Outras tecnologias de armazenamento devem substituir os discos magnticos. A tecnologia de discos de estado slido uma forte candidata.
3.3.1 Discos de Estado Slido

Um disco de estado slido um dispositivo de armazenamento de alto desempenho, constitudo basicamente de chips de memria DRAM e de uma bateria prpria, que assegura a manuteno dos dados, caso o fornecimento de energia seja interrompido [Cas98] [BGI97]. Ele possui a mesma interface de um disco magntico convencional, de modo que as diferenas entre esses dois dispositivos so transparentes para o processador. Os discos de estado slido possuem tempos de acesso extremamente pequenos (menores do que cem microssegundos), inclusive para acessos randmicos, e altas taxas de transferncia. Quando comparados com os discos magnticos, os discos de estado slido apresentam as seguintes vantagens: taxas de transferncia melhores; o acesso a dados no requer operaes de posicionamento, nem apresenta a latncia de rotao dos discos magnticos, levando a tempos de acesso tambm melhores; contribuem para aumentar a utilizao da CPU, porque aceleram as operaes de entrada e sada; so mais resistentes a choques e conseguem prover mais confiabilidade ao sistema, apresentando um excelente MTBF (Medium Time Before Fault), tipicamente de um milho de horas.
41
O maior empecilho para a utilizao macia dos discos de estado slido so os custos elevados. Portanto, os discos magnticos ainda devem permanecer como o meio de armazenamento secundrio padro, pelo menos na prxima dcada. Por essa razo, uma tcnica eficiente de armazenamento estvel de dados, utilizando a tecnologia de discos magnticos, continua sob demanda.
3.4 Tendncias das Aplicaes

Estudos realizados por Baker, no incio da dcada de noventa, j demonstravam o aumento da quantidade de operaes de leitura e escrita nas aplicaes tradicionais [BHK+91]. Mais recentemente, surgiram novas aplicaes, com novos requisitos de armazenamento, tais como[Mud+96]: o processamento de multimdia, que inclui conversas, reconhecimento de voz, codificao e decodificao de imagens de vdeo e videoconferncia; grandes bancos de dados interativos; servidores Web altamente carregados; sistemas crticos de tempo real; transaes de comrcio eletrnico; ambientes de desenvolvimento de aplicaes distribudas e linguagens orientadas a objetos. Essas novas aplicaes pressionam os sistemas de arquivos a melhorarem o desempenho e a confiabilidade. Algumas dessas novas aplicaes exigem alta confiabilidade no armazenamento de dados. Por exemplo, as transaes de comrcio eletrnico e os servios de banco a domiclio requerem que os servidores de arquivos sejam capazes de armazenar dados, de forma estvel. Adicionalmente, precisam oferecer um tempo de resposta aceitvel para o usurio. Portanto, tais aplicaes necessitam de um mtodo de armazenamento estvel, com baixo custo de desempenho. Considerando que a maioria das novas aplicaes utilizam uma infra-estrutura de rede, a tcnica de armazenamento estvel, proposta neste trabalho, constitui uma alternativa vivel.
3.5 Enfoque das Pesquisas Atuais

As pesquisas atuais em sistemas de arquivos visam atender demanda crescente das aplicaes, por armazenamento confivel e de alto desempenho. As tcnicas de otimizao de desempenho disponveis, aplicadas tecnologia corrente, s conseguem atender s necessidades de alguns tipos de aplicaes. Com o uso de grandes memrias principais, uma aplicao caracterizada por muitas operaes de leitura pode aprimorar o seu desempenho. As aplicaes pautadas em acessos seqenciais a grandes objetos so capazes de explorar o paralelismo da tecnologia RAID, para melhorar, igualmente, o desempenho. Infelizmente, aplicaes que realizam muitas operaes randmicas de escrita continuam prejudicadas pela tecnologia de disco, principalmente quando necessitam garantir a estabilidade dos dados armazenados.
42
O problema reside no fato da tecnologia de memria ser a principal alternativa utilizada para a implementao de tcnicas de otimizao do desempenho. A volatilidade da memria DRAM conduz os sistemas de arquivos a um impasse entre confiabilidade e desempenho [CNR+96]. As aplicaes que necessitam de alto desempenho e admitem alguma perda de dados adotam uma poltica de consistncia de cache do tipo write back, gravando os dados alterados em disco, de forma assncrona, somente quando requisitado pelo mecanismo de substituio de pginas da cache. Essa estratgia diminui a quantidade de acessos a disco, aumentando, dessa forma, o desempenho do sistema, mas no garante a estabilidade dos dados armazenados: enquanto permanecem na memria principal, os dados so vulnerveis a crashes, ou seja, todo o contedo da memria pode perder- se. As aplicaes que necessitam de armazenamento altamente confivel adotam uma poltica de consistncia de cache do tipo write through, ou seja, assim que um dado alterado na cache, o sistema providencia a transferncia desse dado para o disco. O sistema poderia iniciar a gravao do dado alterado e retornar imediatamente o controle para a aplicao. Entretanto, para garantir a estabilidade dos dados, essa gravao realizada de forma sncrona: o controle s retorna para a aplicao quando a informao j est realmente gravada no disco. Essa estratgia leva degradao do desempenho, porque aumenta o nmero de acessos a disco e obriga a aplicao a esperar pelo trmino da gravao fsica dos dados. O sistema de arquivos do UNIX adota como padro uma poltica de consistncia de cache, denominada dalayed write, que espera trinta segundos antes de enviar os dados alterados na cache para o disco [Bac86]. Essa estratgia minimiza a degradao do desempenho, causada pelas operaes de escrita, se comparada com a poltica de write through. No entanto, torna inevitvel a perda total dos dados escritos nos ltimos trinta segundos, anteriores a um crash [OCH+85]. Alm disso, o ganho no desempenho limitado, pois estudos demostraram que 1/3 a 2/3 do total de dados escritos continuam vlidos aps os trinta segundos [BHK+91] e so, portanto, inevitavelmente gravados em disco. As aplicaes que necessitam armazenar dados de forma estvel, no UNIX, tambm foram uma gravao sncrona, atravs dos comandos sync ou fsync [AT89].
A menos que a tecnologia corrente ou o comportamento das aplicaes sofram mudanas radicais imediatas, atender simultaneamente aos requisitos de confiabilidade e desempenho um importante desafio para os sistemas de arquivos. Muitos trabalhos foram desenvolvidos, com o objetivo de solucionar esse impasse, e alguns deles esto descritos no prximo captulo.
43
3.6 Concluses
A discusso sobre as influncias da evoluo tecnolgica evidenciou pontos importantes: os avanos tecnolgicos trouxeram benefcios ao desempenho de sistemas de arquivos; os componentes de hardware dos sistemas de arquivos evoluem em ritmos diferentes: a velocidade dos processadores apresenta uma taxa de crescimento bem maior do que a velocidade de acesso aos discos magnticos, condenando a tecnologia de disco a tornar-se um entrave progressivamente maior ao desempenho dos sistemas de arquivos; a tecnologia de rede apresenta taxas de transferncia cada vez maiores, mas esse recurso ainda pouco utilizado nas tcnicas de otimizao de sistema de arquivos; existe uma tendncia unnime dos sistemas de arquivos existentes, de utilizar a memria principal para amenizar o impacto negativo da tecnologia de disco. Entretanto, as tcnicas de otimizao baseadas em memria pouco beneficiam as operaes de escrita, especialmente quando a aplicao requer armazenamento estvel; os sistemas de arquivos carecem de uma nova tcnica de armazenamento estvel de dados, capaz de atender aos requisitos de desempenho e confiabilidade das aplicaes.
O SALIUS tem o objetivo de oferecer alta confiabilidade no armazenamento. Adicionalmente, considerando os dados existentes sobre as velocidades de acesso: processador-disco, processador-memria e memria-memria (via rede), uma implementao eficiente do servio provavelmente levar a um sistema capaz de oferecer armazenamento estvel, com desempenho superior gravao sncrona de dados.
44
Captulo 4
4 Sistemas de Arquivos Robustos: Estado da Arte
O contexto atual dos sistemas de arquivos exige solues para que os requisitos de desempenho e confiabilidade sejam atendidos satisfatoriamente. Muitos trabalhos foram desenvolvidos nesse sentido. Alguns enfocam somente a questo do desempenho e buscam solues para diminuir a quantidade de acessos a disco, ou para tornar as operaes de escrita em disco mais eficientes. Outros preocupam-se tambm com a confiabilidade e sugerem mtodos para tornar a memria principal capaz de armazenar dados, de forma persistente. Este captulo descreve trabalhos importantes e apresenta uma anlise crtica dos resultados obtidos.
4.1 Sistema de Arquivos Baseado em Log

Um sistema de arquivos baseado em log - Log File System (LFS), como o Sprite LFS [RO92] e o BDS LFS [SBM+93], aquele que organiza fisicamente as informaes do sistema de arquivos na forma de um nico e contnuo log seqencial. O log a nica estrutura de dados do disco. Os blocos de dados e todas as estruturas do sistema de arquivos, porventura alterados durante uma operao de escrita, so agrupados em buffers, na memria principal, sendo posteriormente gravados no disco, de forma seqencial, atravs de uma nica operao de sada. Assim, um sistema baseado em log consegue minimizar a quantidade de acessos a disco e de posicionamentos decorrentes de operaes de escrita, promovendo um ganho substancial no desempenho [OD88]. A disposio fsica das informaes no disco influencia no tempo consumido nas operaes de leitura e escrita de dados. O acesso a um bloco de dados, pertencente a um determinado arquivo, requer a leitura prvia de metadados, contendo informaes de localizao. A escrita de um bloco de dados pode implicar na escrita de metadados que o referenciam.
Captulo 4 Sistemas de Arquivos Robustos: Estado da Arte 45
Num LFS, que mantm os blocos de um arquivo e seus respectivos metadados situados em posies fsicas consecutivas, o acesso a um bloco de dados pode ser realizado atravs de um nico acesso a disco. Em contraposio, na maioria dos sistemas de arquivos, que seguem a organizao de disco do UNIX FFS (Unix Fast File System) [MJL+84], mantendo dados e metadados fisicamente espalhados no disco, uma operao de leitura, ou de escrita de dados, pode provocar vrios acessos a disco, intercalados com posicionamentos da cabea de leitura e gravao. Por exemplo, o UNIX FFS precisa realizar, pelo menos, cinco operaes de sada durante a criao de um arquivo: dois acessos para os atributos de arquivo, pelo menos um acesso para os dados do arquivo, um acesso para os dados do diretrio e outro para os atributos do diretrio. Nos sistemas de arquivos baseados em log, a criao de um arquivo pequeno pode ser realizada com uma nica operao de escrita em disco. O LFS possui estruturas de ndices similares quelas utilizadas pelo UNIX FFS (diretrios, ns-i, blocos diretos e blocos indiretos). A principal diferena que no LFS os ns-i no esto localizados em posies fixas no disco. Quando o LFS altera um bloco de dados, ele sabe que dever grav-lo no final do log. Ento, atualiza o n-i do arquivo, para apontar para a nova posio do bloco alterado e, finalmente, grava o bloco de dados, seguido do n-i, de uma s vez, no final do log. Essa diferena a chave para reduzir o nmero de posicionamentos e de operaes de sada, em requisies contendo pequenas modificaes de arquivos. Quando os ns-i esto em posies fixas, como no UNIX FFS, as alteraes de ns-i, blocos de diretrio e blocos de dados de um arquivo causam pequenas transferncias no seqenciais para o disco.
dir1
dir2 Disco Tipos de blocos N-i Diretrio Dado Mapa de Ns-i
arq1
arq2 1 arq1
LFS arq2 1 Disco UNIX FFS
dir1
dir2
Figura 4.1: Uma comparao da organizao de disco do LFS com a do UNIX.
Captulo 4 Sistemas de Arquivos Robustos: Estado da Arte
46
A Figura 4.1 mostra como os atributos, os dados e os ndices so alocados no log do LFS e compara a organizao do disco com a do UNIX FFS. A figura apresenta o contedo do disco, nos dois sistemas de arquivos, aps a criao de dois novos arquivos, denominados respectivamente de dir1/arq1 e dir2/arq2, cada um contendo apenas um nico bloco de dados. Cada sistema de arquivos grava o novo bloco de dados e o n-i para arq1 e arq2, mais o novo bloco de dados e o n-i para os diretrios dir1 e dir2. O UNIX FFS requer vrias operaes de sada no-seqenciais, enquanto o LFS armazena todas as informaes necessrias em uma nica e grande operao de escrita para disco.
4.1.1 Localizao e Leitura de Dados

Embora os sistemas de arquivos baseados em log simplifiquem as operaes de escrita, eles complicam potencialmente as leituras randmicas, pois um bloco pode estar localizado em qualquer lugar do log, a depender de onde ele foi gravado. Alm disso, os ns-i se movimentam no log. Para localizar os ns-i, o LFS adiciona um nvel de indireo, chamado de mapa de ns-i (imap), que contm a posio corrente de cada n-i. O mapa de ns-i consultado e atualizado com muita freqncia. Assim, para assegurar um bom desempenho, o LFS realiza caching do mapa de ns-i e o divide em blocos que, quando alterados, so gravados no final do log, sem a necessidade de posicionamentos extras. Os endereos dos blocos do mapa de ns-i permanecem sempre na memria. Periodicamente, o LFS grava esses endereos numa regio fixa de checkpoint (salvaguarda) do disco.
4.1.2 Recuperao de Crash

A regio de checkpoint contm as informaes bsicas para o procedimento de recuperao do LFS, como a localizao dos blocos do mapa de ns-i. Aps um crash, o LFS l as informaes do ltimo checkpoint e realiza uma recuperao para frente, varrendo o log, a partir da primeira posio gravada aps o ltimo checkpoint, e realizando aes corretivas. Quando uma operao de recuperao termina, o mapa de ns-i contm as localizaes de todos os ns-i do sistema e os ns-i apontam para todos os blocos de dados. Quanto maior a freqncia na qual os checkpoints so gravados, menor o tempo gasto na recuperao do sistema de arquivos, aps um crash [Mck96]. Porm, o intervalo de tempo entre os checkpoints deve ser grande o suficiente, de forma a compensar o tempo gasto com a gravao deles. Adicionalmente, o LFS mantm um Log de Operaes de Diretrios, que utilizado pelo procedimento de recuperao, para restaurar a consistncia entre arquivos e diretrios do sistema.
4.1.3 Gerncia de Espao Livre

Outro aspecto importante do LFS a necessidade de gerenciar o espao do disco, de modo que grandes extenses de espao livre estejam sempre disponveis para a gravao de novos dados. Quando o sistema de arquivos criado, todo o espao livre est numa nica extenso do disco. No momento em que o log atingir o final do disco, o espao livre j ter sido fragmentado em pequenas extenses, correspondentes aos arquivos ou blocos, apagados ou reescritos. O LFS divide o espao do disco em segmentos e utiliza um mecanismo de limpeza que gera segmentos livres, atravs de uma estratgia que combina encadeamento e cpia. Os blocos vlidos de segmentos parcialmente ocupados so copiados e agrupados num segmento livre. Os segmentos restantes so marcados como limpos e encadeados numa lista de segmentos livres, atravs da qual o log cresce.
4.1.4 Sistemas Distribudos Baseados em Log

Os sistemas distribudos Zebra [HO95] e xFS [ADN+95] combinam LFS com RAID (Redundant Array of Inexpensive Disks) [CLG+94]. Os conceitos de RAID so implementados por software, utilizando-se os discos espalhados ao longo da rede. Assim, conseguem resolver o problema de custo apresentado pelos sistemas que implementam RAID, atravs de um hardware especial. Tanto no xFS, quanto no Zebra, as alteraes realizadas sobre um arquivo so mantidas num log privativo do cliente. Quando as alteraes terminam, o log dividido em fragmentos, que so enviados para diferentes discos de servidores, espalhados pela rede. Um disco dedicado a manter informaes de paridade referentes aos diversos fragmentos, adotando o mesmo mecanismo de espalhamento de dados utilizado nos sistemas RAID implementados por hardware. A Figura 4.2 ilustra como os sistemas Zebra e xFS espalham os dados nos discos distribudos ao longo da rede. Cada cliente agrupa os dados das operaes de escrita num log seqencial, na memria principal. O cliente 1 divide seu log nos segmentos 1, 2 e 3, enquanto o cliente 2 divide seu log nos segmentos A, B e C. Cada cliente monta um segmento de paridade, calculado a partir dos segmentos de dados de seu respectivo log. A seguir, os clientes enviam os seus segmentos para diferentes discos de servidores. Assim, o disco 1 armazena os segmento 1 do cliente 1 e o segmento A do cliente 2, e assim sucessivamente, at o ltimo disco, neste caso, o disco 4, que armazena os segmentos com as informaes de paridade.
48
Memrias de clientes Log de escrita do cliente1 Log de escrita do cliente2 Segmento de log Segmento de log
Fragmentos do log
Fragmento de paridade
Fragmentos do log
Fragmento de paridade
3
REDE
1 A
2 B
3 C
Discos de servidores
Figura 4.2: Distribuio de dados nos sistemas Zebra e xFS.
Nos dois sistemas, preciso existir um mecanismo de limpeza de segmentos que cria segmentos limpos e um gerente de arquivos que informa onde os clientes armazenam os dados ao longo do log. As principais diferenas entre os dois sistemas so: no sistema Zebra, os clientes espalham os dados dos seus logs por todos os discos da rede, enquanto no xFS, existem grupos de espalhamento de dados, ou seja, cada cliente espalha os dados de seu log apenas nos discos que pertencem ao seu grupo; no sistema Zebra, o gerenciamento centralizado, existindo apenas um gerente de arquivos e um nico limpador de segmentos, enquanto no xFS, o gerenciamento descentralizado, ou seja, existem vrios gerentes de arquivos e uma tabela, globalmente replicada, associa cada arquivo ao seu gerente, possibilitando que qualquer cliente possa identificar rapidamente o gerente de um arquivo. Alm disso, o xFS implementa um limpador de segmentos distribudo.
4.1.5 Resultados e Anlise Crtica

LFS uma tcnica de armazenamento em disco, cujo objetivo principal obter excelente desempenho nas operaes de escrita, que gravam pequenas quantidades de dados. Os sistemas de arquivos baseados em log, citados neste texto, conseguem atingir tal objetivo.
Agrupando os dados alterados na memria, para depois grav-los, atravs de uma nica e contnua operao de sada, o LFS consegue utilizar plenamente a banda passante do disco. Porm, essa estratgia diminui a confiabilidade do sistema. A ocorrncia de um crash provoca, necessariamente, a perda de dados. O mecanismo de recuperao para frente leva o sistema a um estado consistente, considerando apenas o contedo j gravado no log, antes da falta. O sistema no consegue recuperar os dados que estavam na cache no momento imediatamente anterior ao crash. Portanto, o LFS no consegue prover armazenamento estvel de dados. Os resultados das pesquisas realizadas demonstraram que o LFS s apresenta vantagens de desempenho sobre o UNIX FFS nas pequenas operaes de escrita. Em escritas longas e nas operaes de leitura, ambos os sistemas apresentam desempenhos equivalentes. Assim, os resultados do LFS so vantajosos apenas no ambiente para o qual foi projetado, ou seja, aquele cujas aplicaes realizam um grande nmero de pequenas operaes de escrita. A contribuio dos sistemas baseados em log, aumentando eficincia da utilizao dos discos magnticos, durante o processamento de pequenas requisies de escrita, apenas ameniza, mas no resolve o impacto negativo dessa tecnologia no desempenho. A natureza mecnica dos discos magnticos dificulta a reduo do tempo de acesso, predestinando o aumento da discrepncia existente entre a velocidade dos processadores e a velocidade de acesso a disco. O LFS tambm apresenta problemas de segurana, pois no consegue garantir privacidade de dados [Sta97]. Ele sempre aloca blocos novos, no final do disco, para gravar os novos dados. Portanto, as informaes apagadas do sistema de arquivos no so sobrescritas de imediato e permanecem no disco por algum tempo.
4.2 Cache de Memria No-Voltil

A utilizao de pequenas quantidades de memria no-voltil, denominada NVRAM (Non-Volatile Random Access Memory), contribui para o aumento do desempenho e da confiabilidade de sistemas de arquivos. Uma memria no-voltil, tal qual uma memria RAM (Random Access Memory) com bateria sobressalente, permite a diminuio do trfego de escrita. Armazenando dados em uma NVRAM, pode-se garantir sua permanncia, sem o custo de transferir tais dados da cache de cliente para a cache de servidor, ou da cache de servidor para o disco. Muitos trabalhos j comprovaram os benefcios da adio de memria no-voltil na cache de servidor: a introduo de NVRAM em caches de servidores de sistemas de arquivos UNIX FFS [MJL+84], num ambiente NFS [SGK+85], reduziu o trfego para disco em torno de cinqenta por cento [MSC+90]; de forma similar, a controladora de disco 3990-3, da IBM, utilizava quatro megabytes de NVRAM [MH88].
O trabalho de Mary Baker [BAD+92] estendeu os benefcios da memria no-voltil para o escopo de sistema de arquivos distribudo, demonstrando que a adio de pequenas quantidades de NVRAM, na memria cache de clientes, pode diminuir o trfego de rede cliente-servidor, decorrente de operaes de escrita. Esse trabalho foi implementado no sistema de arquivos Sprite LFS [RO92] e pode ser dividido em dois tpicos principais: a utilizao de NVRAM na cache de cliente e a utilizao de NVRAM na cache de servidor.
4.2.1 Memria No-Voltil na Cache de Cliente

A utilizao de NVRAM na cache de cliente permite que os dados alterados permaneam mais tempo na cache, antes de serem enviados de volta ao servidor. O sistema Sprite adota uma poltica de consistncia de cache, denominada Propagao Retardada [NWO88]: o sistema espera um tempo de trinta segundos, antes de enviar um bloco modificado na cache de um cliente para o servidor; todo cliente executa um procedimento de limpeza de cache, a cada cinco segundos, que envia de volta ao servidor os dados gravados na cache h mais de trinta segundos. Com a adio de NVRAM na cache de cliente, o sistema Sprite passou a assegurar a estabilidade dos dados gravados na cache no-voltil. Por isso, o envio peridico de dados modificados foi desabilitado. Os dados s retornam ao servidor por solicitao do mecanismo de substituio de pginas da cache, ou do mecanismo de controle de concorrncia do sistema. As operaes sync e fsync tambm foram modificadas e passaram a retornar, imediatamente, sem forar o envio de dados para o servidor. Foram implementados dois modelos de cache com NVRAM: no modelo de cache write-aside, a NVRAM utilizada apenas como cpia de segurana dos dados alterados na cache. Todas as operaes de escrita so direcionadas tanto para a cache voltil, quanto para a NVRAM. Isso aumenta o trfego de dados no barramento de memria. As operaes de leitura no fazem acesso NVRAM; no modelo de cache unified, a NVRAM intensamente integrada com a cache voltil. Os blocos modificados por operaes de escrita residem somente na NVRAM. Assim, as operaes de escrita geram trfego apenas para a NVRAM. Os blocos lidos do servidor podem residir em ambas as caches: quando a cache voltil est cheia, o bloco lido pode ser armazenado na NVRAM, caso exista espao disponvel.
O modelo de cache unified apresenta vantagens sobre o modelo write-aside, pois gera menos trfego no barramento de memria, contribuindo, dessa forma, para um melhor desempenho do sistema. Alm disso, o espao da NVRAM tambm utilizado para armazenar dados solicitados por operaes de leitura.
51
4.2.2 Memria No-Voltil na Cache de Servidor

A memria no-voltil utilizada na cache de servidor para reduzir a quantidade de operaes de escrita para disco. Em BAD+92, a propagao peridica de dados para disco foi desabilitada. Um bloco alterado na NVRAM somente gravado em disco quando ele escolhido pelo mecanismo de substituio de blocos da cache. Muitos dados so apagados antes da gravao, o que reduz ainda mais a quantidade de acessos a disco. Adicionalmente, os dados podem ser agrupados e ordenados, de forma que a operao de gravao gere o menor nmero possvel de posicionamentos mecnicos no disco.
4.2.3 Dificuldades na utilizao de NVRAM

Existem dificuldades para incorporar a NVRAM ao projeto de um sistema de arquivos. A primeira grande dificuldade est relacionada com a disponibilidade dos dados alterados na cache de cliente. Quando um cliente falha e existem blocos alterados em sua NVRAM, se o cliente no conseguir se recuperar rapidamente, esses dados permanecem indisponveis. Assim, o servidor no pode atender s solicitaes de leitura desses dados. A soluo apresentada em [BAD+92] transferir a NVRAM para outra mquina operante, com o objetivo de tornar disponveis os dados armazenados. Para que seja possvel realizar a leitura dos dados em outra mquina, os blocos da NVRAM devem ser capazes de se auto-identificarem. A segunda dificuldade diz respeito ao protocolo de cache de cliente. O sistema deve garantir a persistncia dos dados armazenados na cache no-voltil de um cliente. Por isso, o protocolo de cache de cliente precisaria ser alterado, para no liberar imediatamente da cache os dados enviados de volta ao servidor, mas esperar que esses dados sejam gravados em disco. Uma segunda opo seria forar uma gravao sncrona desses dados, no disco do servidor. O artigo BAD+92 sugere a utilizao de NVRAM na cache de servidor, permitindo que os dados da cache de cliente sejam liberados, to logo sejam recebidos na cache no-voltil do servidor.
4.2.4 Resultados Obtidos

Os testes utilizaram como plataforma o sistema distribudo Sprite [OCD+88], com sistema de arquivos Sprite LFS, e chegaram aos seguintes resultados [BAD+92]: a introduo de apenas um megabyte de NVRAM na memria cache de clientes conseguiu reduzir o trfego de rede cliente-servidor em quarenta a cinqenta por cento; o aumento da quantidade de NVRAM utilizada no melhorou significativamente os resultados obtidos;
52
o modelo de cache unified atingiu resultados melhores que o modelo write-aside, contribuindo para reduzir o trfego cliente-servidor, tanto nas operaes de leitura, quanto nas operaes de escrita; a introduo de memria NVRAM na cache de servidor resultou numa reduo de, pelo menos, vinte por cento dos acessos a disco, chegando at noventa por cento, numa simulao com o mesmo sistema de arquivos, sob utilizao intensa.
4.2.5 Anlise Crtica

A utilizao de cache de memria no-voltil melhora o desempenho de um sistema de arquivos, pois consegue reduzir tanto quantidade de acessos a disco, quanto o trfego cliente-servidor, possibilitando que os dados passem mais tempo na cache e aumentando, assim, a probabilidade de que esses dados sejam absorvidos na prpria cache. Porm, as melhorias no desempenho so limitadas, porque a NVRAM est atrelada a um barramento de memria: a sobrecarga do barramento restringe o desempenho dos acessos NVRAM. A NVRAM consegue prover armazenamento estvel, at certo ponto, pois os dados gravados em memria no-voltil sobrevivem a crashes do sistema. Entretanto, se o fluxo de dados das operaes de escrita torna-se maior que a capacidade da NVRAM, o sistema passa a transferir dados para o disco. Para garantir a estabilidade desses dados, a gravao em disco precisa ser realizada de forma sncrona. Nesse caso, a NVRAM no apresenta vantagens sobre o armazenamento estvel em um sistema de arquivos tradicional.
4.3 Rio File Cache

O principal objetivo do Rio File Cache [CNR+96] tornar a memria RAM capaz de sobreviver a crashes de sistema operacional. Para isso, o trabalho adota duas linhas de ao: impede que a memria seja sobregravada acidentalmente pelo sistema, durante um crash, e prov o sistema de um mecanismo de recuperao do tipo warm reboot.
4.3.1 Proteo de Memria

O mecanismo de proteo de memria do Rio File Cache fundamenta-se no controle de acesso s pginas da cache: utiliza uma tcnica denominada code patching, que impede que rotinas no-autorizadas gravem dados na cache. Essa tcnica implementada atravs da alterao do cdigo do ncleo do sistema operacional. Todas as rotinas do ncleo, que gravam dados na memria, so acrescidas de instrues que verificam se o endereo de armazenamento de uma pgina de cache. Somente as rotinas de manipulao de cache tm permisso explcita para gravar dados na rea de cache. A utilizao do mecanismo de proteo de memria opcional e aumenta a confiabilidade do sistema de arquivos.
53
4.3.2 Mecanismo de Recuperao

O mecanismo de recuperao do Rio File Cache pressupe que o sistema capaz de preservar, por algum tempo, o contedo da memria principal e da cache de processador, aps um reincio normal do sistema. Assim, depois de um crash, o sistema atualiza o sistema de arquivos com o contedo presente na cache. O sistema mantm e protege uma rea de memria chamada registro, contendo as informaes necessrias para localizar, identificar e restaurar dados e metadados de arquivos, a partir dos buffers da cache. A recuperao realizada em duas fases: logo que o sistema reinicia, o mecanismo de recuperao grava todo o contedo presente na memria principal, antes do crash, na partio de permuta do disco. A seguir, grava os metadados atualizados no sistema de arquivos do disco, usando para isso os endereos de disco armazenados no registro. Assim, o sistema de arquivos fica intacto antes do programa de recuperao fsck ser executado; quando o sistema finaliza todos os procedimentos de reincio, um processo, no nvel de usurio, analisa os dados gravados na partio de permuta e restaura o contedo da memria principal.
4.3.3 Efeitos no Projeto de Sistema de Arquivos

O Rio File Cache operou algumas alteraes no comportamento do sistema de arquivos, para reduzir a freqncia de operaes de sada para disco: a gravao peridica dos dados em cache foi desabilitada; a rotina panic foi modificada, evitando gravar dados para disco antes de um provvel crash. As rotinas sync e fsync foram alteradas para retornar imediatamente, sem forar a gravao sncrona de dados. Assim, as operaes de escrita para disco passaram a ocorrer somente durante a substituio de pginas de memria. Adicionalmente, o Rio File Cache possibilitou a ordenao das alteraes de metadados na cache, do mesmo modo como feito nas operaes de escrita em disco, minimizando a possibilidade de produzir inconsistncias durante um crash. Esse sistema conseguiu, tambm, aplicar atomicidade escrita de metadados crticos, utilizando um esquema de cpias de pginas: antes de alterar uma pgina da cache contendo metadados crticos, o sistema copia o seu contedo, numa nova pgina de memria, e faz com que o registro aponte para essa cpia; quando a operao termina, o sistema faz com que o registro volte a apontar para a pgina original da cache, com os metadados j alterados.
54
4.3.4 Suporte de Arquitetura Necessrio

A memria do sistema e a cache do processador devem ser capazes de preservar seus respectivos contedos, aps um reincio normal do sistema. Equipamentos do tipo DEC Alphas possuem essa caracterstica [DEC94]. No entanto, a maioria dos computadores no possui essa facilidade. O mecanismo de proteo causa um impacto negativo no desempenho do sistema: as rotinas do ncleo precisam executar instrues adicionais de verificao, toda vez que vo escrever dados na memria, para assegurar que apenas as rotinas de manipulao de cache gravem dados na rea de cache. Otimizaes de cdigo foram implementadas, com o objetivo de minimizar esse impacto. Para tornar o mecanismo de proteo simples e eficiente, seria necessrio um suporte de hardware, para implementar um controlador de memria capaz de impedir escritas no-autorizadas em certas pginas fsicas [BMR+91], nesse caso, as pginas de cache. Uma implementao simples desse controlador pode ser realizada, acrescentando-se a cada pgina de memria um bit de permisso de escrita e mapeando as permisses no espao de endereamento do processador [CNR+96]. Assim, o sistema poderia utilizar os bits de permisso de escrita para substituir o esquema de code patching do mecanismo de proteo.
4.3.5 Resultados e Anlise Crtica

O Rio File Cache consegue, de fato, tornar a memria principal apta a sobreviver a crashes de sistema operacional [CNR+96]. A confiabilidade atingida, mesmo sem o mecanismo de proteo de memria, equivalente a de um sistema de arquivos que adota a poltica de cache write through, enquanto seu desempenho vinte vezes maior. O Rio torna todas as operaes de escrita imediatamente permanentes e ainda executa mais rpido do que sistemas como o UNIX FFS, que adotam a poltica de Propagao Retardada dos dados da cache para o disco. O mecanismo de proteo de memria pode ser utilizado para tornar o sistema ainda mais confivel, causando, entretanto, uma queda no desempenho. Apesar dos resultados obtidos com esse trabalho serem bastante positivos, o sistema depende da disponibilidade de um hardware especial, que no comum nos computadores utilizados em larga escala. A adaptao de um sistema distribudo, de modo que todos os computadores contenham esse recurso, implica em altos custos. Portanto, o Rio File Cache no consegue prover armazenamento estvel de dados a um custo acessvel.
55
4.4 Sistema de Armazenamento em Memria No-Voltil

Flash RAM um tipo de memria no-voltil, isto , consegue armazenar dados de forma persistente. Porm, apresenta problemas bsicos, quando utilizada para prover um sistema de memria no-voltil de propsito geral. No obstante, alguns trabalhos, dos quais pode-se destacar o eNVy [WZ94], fazem uso da tecnologia Flash, com esse propsito. Um chip Flash estruturalmente e funcionalmente muito similar a um chip EPROM (Erasable Programable Read-Only Memory), exceto pelo fato de seu contedo ser eletricamente removvel [Int94]. Cada chip consiste de um extenso vetor de bytes, formado por clulas de memria no-voltil. Embora a estrutura simples desses chips permita que sejam fabricados em larga escala e a um baixo custo, a memria Flash RAM no utilizada vastamente porque apresenta algumas deficincias bsicas [WZ94]: nos chips Flash, os dados no podem ser gravados sobrepondo o contedo anterior, ou seja, o contedo antigo precisa ser apagado, antes que novos dados sejam gravados. Adicionalmente, a remoo de dados num chip Flash s acontece em grandes volumes, o que significa que todo o contedo do dispositivo removido numa nica e demorada operao, que dura cerca de cinqenta milissegundos. A tecnologia Flash mais recente permite alguma flexibilidade, atravs da diviso do vetor de memria em blocos, que podem ser apagados de forma independente. Desse modo, cada operao de remoo apaga somente um bloco, em vez de apagar todo o banco de memria. Ainda assim, a operao de remoo bastante lenta, se comparada com outros tipos de memria; uma operao de programao/remoo de dados gasta muito mais tempo que uma operao de leitura. Uma leitura arbitrria pode ser realizada com tempo de acesso prximo ao de uma memria DRAM (setenta nanossegundos) [AMD99]. A tecnologia Flash mais sofisticada divide a memria em pginas, para otimizar a leitura, sendo que o acesso inicial a uma pgina pode ser realizado em sessenta e cinco nanossegundos e, desse ponto em diante, a leitura de um dado, localizado em uma posio qualquer da pgina, pode ser realizada em apenas vinte e cinco nanossegundos [AMD99a]. Em contraposio, a programao de bytes individuais bem mais lenta, durando de quatro a dez microssegundos, e ainda deve esperar que o contedo anterior seja apagado; a memria Flash RAM possui tempo de vida til limitado. O mtodo de programao utilizado pela tecnologia Flash degrada, gradualmente, o tempo de programao e de remoo do contedo da memria, cada vez que essas operaes so executadas. Um chip falha quando uma operao de programao ou de remoo leva mais tempo do que o permitido na especificao. Cada fabricante garante um nmero mnimo de ciclos de programao/remoo dentro de uma faixa de tempo preestabelecida. Esse nmero varia de dez mil a um milho de vezes [AMD99].
56
4.4.1 Sistema eNVy

O eNVy [WZ94] utiliza a memria Flash RAM como a base para um sistema de armazenamento no-voltil em memria principal, adotando uma variedade de tcnicas para superar as deficincias apresentadas pela tecnologia Flash. O eNVy adota um esquema de cpias de pginas na escrita, simulando para o processador que os dados sobrepem o contedo antigo. O vetor de memria tratado como um espao linear de endereamento, dividido em pginas. Uma tabela de pginas mapeia o endereo lgico linear, apresentado ao processador, para um endereo fsico no chip Flash. Quando o processador requisita que dados sejam armazenados num endereo especfico, o eNVy faz uma nova cpia da pgina correspondente, incluindo os dados atualizados, e altera a tabela de pginas para que aponte para a nova verso. Como a programao da memria Flash RAM uma operao lenta, durante a atualizao de uma pgina de memria, a nova verso desta criada num outro tipo de memria: o eNVy utiliza uma pequena quantidade de memria SRAM (Synchronous Random Access Memory), com bateria sobressalente. A tabela de pginas passa a apontar para a pgina escrita na SRAM. A tabela de pginas tambm mantida na SRAM, pois sofre atualizaes constantes. O gerenciamento da SRAM realizado atravs de uma poltica simples de fila. proporo que a SRAM vai atingindo um nvel de enchimento preestabelecido, suas pginas vo sendo gravadas na memria Flash. Se no existir espao livre na memria Flash, uma operao de limpeza realizada. O algoritmo de limpeza utilizado pelo eNVy funcionalmente similar ao algoritmo de limpeza do LFS [RO92]. Algumas simulaes do sistema eNVy foram realizadas, utilizando-se as memrias Flash RAM e SRAM, com as caractersticas apresentadas na Tabela 2.1.
TIPO DE MEMRIA
Flash RAM SRAM
QUANTIDADE
2 Gb 16 Mb
TEMPO DE LEITURA
85 ns 85 ns
TEMPO DE ESCRITA
4 10 ms 85ns
Tabela 2.1: Caractersticas das memrias utilizadas na simulao do sistema eNVy. Os resultados da simulao foram os seguintes: tempo de latncia mdio de cento e oitenta nanossegundos, para as leituras, e de duzentos nanossegundos, para as escritas;
57
conforme a taxa de transaes por segundo for aumentando, mais dados vo sendo armazenados na memria. Quando o nvel de enchimento da Flash RAM ultrapassa oitenta por cento, o tempo das operaes de escrita aumenta para aproximadamente sete microssegundos, devido ao tempo consumido pelo mecanismo de limpeza.
4.4.2 Anlise Crtica

O sistema eNVy foi projetado para aplicaes com base de dados de pequeno e mdio portes. O desempenho do sistema eNVy est atrelado taxa de transaes por minuto e quantidade de dados armazenada pela aplicao. Assim, o eNVy no pode ser utilizado de forma genrica. Somente algumas aplicaes, com o comportamento previsvel, podem beneficiar-se desse sistema. Portanto, a tecnologia de memria Flash ainda precisa superar suas deficincias, para que possa ser utilizada como principal dispositivo de armazenamento estvel de um sistema de arquivos de propsito geral.
4.5 Concluses
A Tabela 4.1 resume as principais caractersticas dos diversos trabalhos apresentados neste captulo. Todos eles visam melhorar o desempenho dos sistemas de arquivos e apresentam resultados positivos, em maior ou menor escala. Em alguns casos, o desempenho do sistema s vantajoso para um ambiente especfico, como alguns sistemas baseados em log [RO92] [SBM+93], projetados para aplicaes com predominncia de pequenas operaes de escrita, como os sistemas de automao de escritrio, e o sistema eNVy [WZ94], projetado para aplicaes com base de dados de pequeno e mdio portes. A melhoria no desempenho provida por sistemas baseados em log [ADN+95] [HO95] [RO92] [SBM+93] resulta da utilizao mais eficiente dos discos, durante as operaes de escrita. Assim, conseguem amenizar, temporariamente, o impacto negativo da tecnologia de disco magntico no desempenho. Porm, as tendncias da tecnologia, apresentadas no captulo anterior, apontam a necessidade de desvincular o desempenho do sistema do desempenho dos discos, o que no acontece em tais sistemas. A utilizao de cache de NVRAM [BAD+92] s consegue prover ganhos no desempenho enquanto a memria NVRAM tiver capacidade para armazenar os dados das operaes de escrita, evitando acessos a disco. Um aumento do trfego de escrita pode esgotar o espao da NVRAM, gerando a necessidade de transferir dados para o disco.
58
Os sistemas baseados em log no garantem a estabilidade dos dados armazenados. Os demais trabalhos apresentados conseguem garantir confiabilidade no armazenamento de dados: a cache de NVRAM, o Rio File Cache [CNR+96] e o sistema eNVy [WZ94]. Eles buscam capacitar a memria principal para armazenar dados de forma estvel. Todos utilizam algum hardware especial, ou seja, dispositivos que no fazem parte da arquitetura dos computadores utilizados em larga escala. A adoo desses dispositivos especiais geralmente implica em custos altos. Somente os sistema baseados em log e o Rio File Cache incluem um mecanismo de recuperao de crash. No caso dos sistemas baseados em log, o procedimento de recuperao utiliza apenas as informaes gravadas no log, para restaurar a consistncia do sistema de arquivos. Desse modo, as informaes presentes na cache, no momento do crash so irremediavelmente perdidas. Com exceo, do sistema eNVy, desenvolvido para um ambiente especfico, os demais trabalhos podem ser utilizados como sistemas de propsito geral. Embora o LFS [RO92] tenha sido desenvolvido para atender as necessidades de um ambiente bem definido, os sistemas baseados em log podem ser utilizados por aplicaes de diversas naturezas, sendo que o desempenho apresentado pode variar de um ambiente para outro.
SISTEMAS BASEADOS EM LOG CACHE DE NVRAM RIO FILE CAHE SISTEMA ENVY
ARMAZENAMENTO
ESTVEL
MELHORIA NO
DESEMPENHO
HARDWARE
ESPECIAL
MECANISMO DE
RECUPERAO
PROPSITO
GERAL
NO SIM SIM SIM
SIM SIM SIM SIM
NO SIM SIM SIM
SIM NO SIM NO
SIM SIM SIM NO
Tabela 4.1: Quadro comparativo de trabalhos relacionados.
Nenhum dos trabalhos apresentados constitui uma tcnica de armazenamento estvel de propsito geral a um custo acessvel, com desempenho superior gravao sncrona de dados, capaz de desvincular o desempenho do sistema do desempenho dos discos e de oferecer um mecanismo de recuperao para frente.
59
Captulo 5
5 Especificao do SALIUS
Este captulo apresenta a especificao de uma nova tcnica de armazenamento estvel, denominada SALIUS SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS , que visa atender, simultaneamente, aos requisitos de confiabilidade e desempenho de aplicaes que necessitam gravar dados de forma estvel, utilizando a tecnologia ora disponvel. Ele descreve os conceitos bsicos e as tcnicas empregadas, incluindo como os sistemas de arquivos so alterados, como a replicao utilizada e como a recuperao de crash realizada. O SALIUS um software capaz de realizar operaes sobre arquivos, de forma estvel, sempre que requisitadas pelos seus clientes. O SALIUS um software complementar ao sistema de arquivos, disponibilizando novas operaes de manipulao de arquivos para os clientes. Um cliente do servio um programa de usurio, ou seja, o mesmo cliente usual de um sistema de arquivos. Um cliente faz requisies ao SALIUS, quando deseja manipular um arquivo de forma estvel. Assim, o SALIUS um complemento do servio de arquivos, capaz de garantir a estabilidade dos efeitos de operaes realizadas sobre arquivos, a despeito da ocorrncia de crashes. Este Captulo apresenta os principais objetivos do SALIUS e os requisitos que devem ser cumpridos pelo servio, descreve o funcionamento geral do SALIUS e a interao entre seus componentes. A seguir, cada parte componente do SALIUS descrita em detalhe. Finalmente, algumas consideraes sobre o desempenho e a confiabilidade do servio so apresentadas.
Captulo 5 Especificao do SALIUS
60
5.1 Principais Objetivos

Estabilidade de Dados. O principal objetivo do SALIUS garantir a estabilidade dos dados, ou seja, preservar os dados armazenados por suas primitivas, independentemente da ocorrncia de crashes no sistema. Desempenho. O servio pretende oferecer um desempenho melhor do que o armazenamento estvel baseado na gravao sncrona de dados. Custo. O servio tem como meta no introduzir custos adicionais ao sistema. Capacidade de Recuperao de Crash. O servio visa oferecer um mecanismo de recuperao capaz de restabelecer o sistema de arquivos a um estado consistente, aps um crash na mquina onde o sistema de arquivos reside, garantindo a estabilidade de todos os dados armazenados atravs de primitivas do SALIUS. Servio de propsito geral. O servio deve atender s necessidades de armazenamento de aplicaes de diversas natureza, no se restringindo a um contexto especfico.
5.2 Requisitos
O SALIUS deve atender a certos requisitos, para que consiga atingir os seus objetivos.
5.2.1 Semntica de Falha

O projeto de um Servio de Armazenamento Estvel deve especificar a semntica de falha assumida para o sistema. O tipo de semntica de falha influencia na especificao do comportamento do servio, para que possa garantir a estabilidade dos dados armazenados. Por exemplo, se um projeto assume uma semntica de falha por crash e/ou valor, para a operao de recuperao de dados armazenados em disco, ento ele deve prever a replicao de dados em discos diferentes. Se o projeto tambm assume que o sistema apresenta uma semntica de falha por valor, em resposta s requisies de leitura de dados armazenados na memria principal, significa que os dados em memria podem ter seus valores corrompidos e, portanto, o servio deve possuir um mecanismo de proteo de memria, como em [CNR+96]. O SALIUS assume uma semntica de falha por crash. Quando ocorre um crash, o sistema pra, precisando ser reiniciado, para que volte a funcionar. Assim, todo contedo da memria principal voltil perdido. O servio precisa garantir a sobrevivncia dos dados provenientes de todas as operaes de escrita, realizadas atravs de suas primitivas e concludas com sucesso, mesmo que tais dados no tenham sido propagados da memria para o disco, antes do crash. Falhas no meio de armazenamento no-voltil e na memria principal fogem ao escopo deste trabalho.
Captulo 5 Especificao do SALIUS 61
5.2.2 Semntica de Compartilhamento

Semntica de compartilhamento uma especificao dos efeitos de operaes feitas por mltiplos usurios que esto realizando acessos a um mesmo arquivo, simultaneamente. Na prtica, essa semntica deve definir o momento exato em que as modificaes de dados, realizadas por um processo, tornam-se visveis aos demais processos [Tan95]. Como o enfoque da pesquisa foi direcionado para o sistema de arquivos do U NIX, o SALIUS deve manter a mesma semntica de compartilhamento do UNIX. Assim, deve obrigar a uma ordenao das operaes de leitura e escrita, retornando sempre o valor mais recente. Quando uma leitura segue uma escrita, o sistema retorna o valor que acabou de ser escrito. Quando uma leitura segue duas operaes de escrita, o sistema retorna o valor resultante da ltima escrita [Tan95]. Desse modo, os efeitos de uma operao de escrita tornam-se imediatamente visveis, para todos os processos, e o sistema mantm uma imagem nica de cada arquivo.
5.2.3 Transparncia
A transparncia pode ser analisada sob vrios aspectos. Na abordagem do SALIUS, a transparncia se traduz na iluso do usurio de que o comportamento do sistema de arquivos original permanece inalterado. O servio deve esconder da aplicao as aes internas, executadas com a finalidade de prover estabilidade. Para isso, deve ser transparente em alguns aspectos: transparente quanto localizao, ou seja, o programa de usurio no precisa saber onde os dados esto sendo replicados, nem de qual mquina sero recuperados; transparente quanto replicao, ou seja, a aplicao no deve tomar conhecimento de quantas rplicas existem, nem das aes necessrias para manter a consistncia; transparente quanto falha: deve oferecer meios de mascarar falhas, quando possvel, e, quando no, deve efetuar medidas de recuperao.
O SALIUS no precisa prover transparncia de acesso. O modo como um usurio invoca uma operao no servio pode ser diferente da forma como a mesma operao invocada no sistema de arquivos original. Isso porque, para a maioria das operaes, a semntica assumida no SALIUS difere da semntica do sistema de arquivos original. Se comparado com a gravao assncrona de dados, o servio, normalmente, consome mais recursos e apresenta um desempenho inferior, em decorrncia da replicao de dados. Em muitas ocasies, a aplicao no necessita pagar pela estabilidade de dados. Para prover flexibilidade ao usurio, de optar pela utilizao do servio, de acordo com a sua convenincia, a transparncia de acesso pode ser sacrificada.
62
5.2.4 Facilidade de Administrao

O SALIUS no deve introduzir dificuldades na administrao do sistema. O esforo exigido para gerenciar o novo servio precisa ser mnimo. Basicamente, o administrador deve realizar tarefas de configurao, no momento da instalao do servio. Tambm tarefa do administrador executar o procedimento de recuperao, aps um crash.
5.2.5 Independncia de Hardware Especial

A implementao do SALIUS no deve necessitar de um hardware especial. A introduo de um hardware especial num sistema, geralmente, acarreta custos adicionais. Assim, para atender ao objetivo de no onerar custos ao sistema, necessrio que o servio possa funcionar com os componentes de hardware comuns na maioria dos sistemas computacionais.
5.3 Funcionamento Geral do SALIUS

A idia fundamental do SALIUS garantir a estabilidade de dados, minimizando ao mximo a necessidade de realizar gravaes sncronas em disco. Baseando-se no fato de que um acesso memria principal (na ordem de nanossegundos) muito mais rpido do que um acesso a disco (na ordem de milissegundos) e de que a latncia decorrente de um acesso atravs de uma rede de alta velocidade menor do que a latncia introduzida pela leitura de um bloco num disco local [Dah+94], o SALIUS substitui a gravao sncrona de dados pela replicao remota de buffers alterados na cache de arquivos. A estabilidade dos dados garantida, porque todas as estruturas de dados, mantidas na memria principal pelo sistema de arquivos, so copiadas para as memrias principais de diferentes mquinas do sistema distribudo: o sistema de arquivos do UNIX mantm em memria a buffer cache, os ns-i e o superbloco; qualquer alterao nessas estruturas replicada pelo SALIUS. Como a replicao garante a sobrevivncia de, pelo menos, uma cpia dos dados alterados, aps a ocorrncia de um crash, o contedo replicado pode ser recuperado, a partir de uma outra mquina, e gravado no sistema de arquivos em disco. O SALIUS constitudo de quatro componentes bsicos: Interface: um conjunto de primitivas, incorporadas interface do sistema de arquivos e utilizadas pelos programas de usurio para requisitar operaes ao SALIUS; Servidor de Arquivos Complementar (SAC): a implementao das operaes invocadas atravs de primitivas do SALIUS. O SAC realiza operaes sobre arquivos, requisitadas pelos clientes, e interage com o servidor de replicao de buffers, solicitando a replicao dos dados alterados;
63
Servio de Replicao de Buffers: um software que prov a replicao confivel de buffers, ou seja, garante o armazenamento de cpias das alteraes realizadas num sistema de arquivos. Adicionalmente, esse servio fornece as informaes necessrias para restabelecer o sistema de arquivos a um estado consistente, preservando os dados estveis. O Servio de Replicao de Buffers implementado por um ou mais processos Servidores de Replicao de Buffers (SRB) e possui dois tipos de clientes diferentes: o SAC e o Procedimento de Recuperao; Procedimento de Recuperao: um software que restabelece a consistncia do sistema de arquivos, aps um crash. O procedimento de recuperao interage com o SRB para recuperar as informaes replicadas, necessrias para restaurar a consistncia do sistema de arquivos, mantendo as informaes estveis.
Se uma aplicao quiser atualizar um arquivo, de forma estvel, basta invocar uma primitiva do SALIUS. Ento, o controle passa para o Servidor de Arquivos Complementar (SAC), que executa a operao requisitada: para isso, o SAC atualiza as estruturas do sistema de arquivos, em memria, e interage com o Servidor de Replicao de Buffers (SRB), solicitando a replicao de todas as alteraes efetuadas. O SRB realiza a replicao e envia uma resposta ao SAC, confirmando a estabilidade dos dados. Uma mensagem de confirmao s pode ser enviada quando o SRB puder garantir, com uma determinada probabilidade, que a informao est estvel. Somente aps receber a confirmao do SRB, o SAC retorna o controle para o programa de usurio, informando que a operao requisitada foi realizada com sucesso. Se a mensagem de confirmao no chega dentro de um intervalo de tempo predefinido, o SAC assume que o SRB falhou. Nesse caso, o SAC fora a gravao de todos os dados do sistema de arquivos alterados na memria e ainda no propagados para o disco, passando a estabilizar as informaes atravs de gravaes sncronas. Quando o SRB se recupera de uma falha, o SAC volta a utilizar o servio de replicao. O funcionamento bsico do SALIUS pode ser observado na Figura 5.1. A mquina 1 possui um sistema de arquivos, acrescido do Servidor de Arquivos Complementar do SALIUS, e um processo usurio U, que invoca uma primitiva do SALIUS para alterar um arquivo, passando os dados alterados como parmetro, num buffer de usurio. Quando a primitiva executada, o SAC copia esses dados para a buffer cache. Se necessrio, o superbloco e o n-i do arquivo tambm so atualizados. A seguir, num tempo t, o SAC envia as estruturas alteradas para o Servidor de Replicao de Buffers, executando na mquina 2. O SRB recebe as informaes enviadas e, depois de armazen-las na memria principal, envia uma mensagem de confirmao para o SAC. Se o SAC receber uma confirmao, dentro de um intervalo de tempo predefinido ( t ), ento retorna o controle para o processo U, informando o sucesso da operao. Caso contrrio, o SAC detecta que o SRB falhou e realiza a gravao sncrona dos dados em disco, antes de retornar.
Servidor de Arquivos
Servidor de Replicao
rea do usurio rea do ncleo
primitiva Processo U
Buffer de usurio
S
Processo SRB Superbloco Buffer cache Tabela de Ns-i
Processo SAC Buffer cache
t : Estruturas alteradas t': Confirmao Confirmao se t' > t + t Gravao Sncrona
Figura 5.3: Funcionamento bsico do SALIUS.
Se a replicao confirmada no tempo esperado ( t t + t ), os dados alterados na memria principal da mquina 1 permanecem na cache por um certo tempo e depois so gravados em disco, de forma assncrona, como no funcionamento padro do sistema de arquivos do UNIX. Assim, o SALIUS possibilita que o sistema de arquivos do UNIX realize caching de escrita e oferea armazenamento estvel, simultaneamente. A depender da relao entre o volume de dados alterados e a capacidade de memria principal disponvel nas mquinas do sistema, o tempo de permanncia dos dados alterados na cache pode ser aumentado para um valor maior do que o valor padro (que de trinta segundos, no UNIX), contribuindo para um melhor desempenho do sistema. O Servidor de Replicao de Buffers recebe os dados replicados e os armazena num log, mantido inicialmente na memria principal. Quando o espao na memria torna-se escasso, uma parte das informaes replicadas transferida para um disco. Periodicamente, o SRB realiza uma operao de limpeza do log, descartando as informaes que j tenham sido gravadas em disco, na mquina 1. Finalmente, aps um crash, o procedimento de recuperao do SALIUS deve ser executado, para restaurar a consistncia do sistema de arquivos. O procedimento de recuperao envia uma mensagem ao SRB, solicitando todos os dados replicados antes do crash. O SRB responde, fornecendo as informaes requisitadas. A seguir, o procedimento de recuperao grava tais informaes no sistema de arquivos, em disco.
65
O Servio de Replicao de Buffers, ilustrado na Figura 5.1, implementado por um nico processo servidor. Porm, esse servio pode ser implementado por vrias rplicas desse processo, executando em diferentes mquinas do sistema, com o objetivo de aumentar a sua confiabilidade, como no projeto apresentado no Captulo 6.
5.3.1 Tratamento de Falha na Replicao

Quando uma replicao no confirmada no tempo esperado, o SAC assume que o SRB falhou. Por isso, realiza a gravao sncrona, garantindo a estabilidade dos dados provenientes da operao de atualizao em curso. Porm, essa ao no suficiente para preservar a semntica de compartilhamento do servio. Na prtica, o SRB pode continuar operacional, e a falha detectada ser decorrente de algum problema na comunicao entre o SAC e o SRB. Se o sistema sofrer um crash logo aps da gravao sncrona dos dados, o procedimento de recuperao gravar no disco os dados replicados no SRB, antes do crash. O SRB pode conter dados desatualizados, que iro sobrepor informaes mais recentes, armazenadas com a gravao sncrona. A situao descrita pode ser demonstrada com o seguinte exemplo: um bloco x atualizado e replicado no SRB; em seguida, outra operao modifica o mesmo bloco e tenta realizar a replicao, mas o SRB falha e, portanto, x gravado de forma sncrona; a seguir, o sistema de arquivos sofre um crash e o procedimento de recuperao grava o antigo contedo do bloco x, fornecido pelo SRB, violando a semntica de compartilhamento adotada pelo servio, porque uma atualizao antiga sobrepe uma atualizao mais recente. Para preservar a semntica de compartilhamento, o SAC precisa evitar que dados desatualizados permaneam no SRB. Por isso, quando o SRB falha, o SAC grava em disco todas as atualizaes do sistema de arquivos, que ainda esto pendentes na memria, passando a operar atravs de gravaes sncronas. Alm disso, o SRB precisa detectar que falhou e passar por um procedimento de inicializao, que consiste em descartar os dados do log, antes de voltar a atender aos pedidos de replicao. O SAC volta a utilizar o servio de replicao, assim que detecta a inicializao do SRB. A forma como o SRB detecta que falhou e como o SAC detecta uma inicializao do SRB depende do modo como o SRB implementado, mais especificamente, do modelo de replicao adotado, da semntica de falha e do protocolo de replicao do servio. Esses detalhes sero abordados no Captulo 6, que apresenta um projeto de implementao para o Servio de Replicao de Buffers.
66
5.4 Interface do SALIUS

As aplicaes podem invocar as operaes do SALIUS, usando as primitivas do servio, que compem a sua interface. O objetivo dessa interface possibilitar que o usurio continue realizando as principais operaes de alterao, possveis no sistema de arquivos original, com a funcionalidade complementar de prover estabilidade de forma alternativa usual, isto , evitando as gravaes sncronas. Conceitualmente, para cada chamada de sistema de alterao do sistema de arquivos original, existe uma primitiva correlata na interface do SALIUS. Existem duas abordagens possveis para incorporar um Servio de Armazenamento Estvel a um sistema de arquivos: substituindo todas as primitivas originais pelas primitivas do servio, ou adicionando novas primitivas interface do sistema. Na primeira abordagem, o armazenamento estvel passa a ser a nica forma possvel de manipular dados. O servio totalmente transparente ao usurio: ao invocar uma primitiva do sistema de arquivos, o usurio grava dados de forma estvel, automaticamente. Na segunda alternativa, a transparncia cede lugar flexibilidade, pois o usurio opta entre utilizar o SALIUS, ou continuar usando as primitivas tradicionais. A especificao do SALIUS prioriza a flexibilidade, porque muitas aplicaes no necessitam pagar os custos do armazenamento estvel. Alm disso, uma mesma aplicao pode requerer a estabilidade de apenas parte dos dados manipulados. Por exemplo, uma aplicao pode desejar gravar seus arquivos de log e de auditoria, de forma estvel, mas pode prescindir da estabilidade para os demais arquivos. Oferecendo suas primitivas como uma alternativa adicional, para a manipulao de arquivos, o servio propicia ao usurio o benefcio de decidir sobre a convenincia de utilizar o armazenamento estvel. Uma segunda deliberao, muito importante, refere-se granularidade atribuda unidade de armazenamento estvel. O SALIUS assume que a necessidade de armazenamento estvel aplica-se, em geral, a um arquivo inteiro e no a uma frao de arquivo. Por conseguinte, o usurio opta pela utilizao do servio no momento em que abre ou cria um arquivo, indicando explicitamente que o arquivo deve ser manipulado atravs de primitivas do SALIUS. Assim, na especificao do SALIUS para UNIX, no nvel lgico, o servio tambm possui uma nova verso de cada primitiva de alterao do sistema de arquivos original. As primitivas do servio, descritas a seguir, realizam praticamente as mesmas aes que as primitivas do UNIX, somando a replicao de buffers, para garantir a estabilidade de informaes armazenadas.
67
5.4.1 open
A primitiva open utilizada para abrir um arquivo existente, ou criar e abrir um novo arquivo. Atravs dela, o usurio pode optar pela utilizao do SALIUS. Sintaxe: fd = open(pathname, flags, mode)
fd um descritor de arquivo, que retornado para a aplicao; pathname o nome de caminho do arquivo; flags uma combinao de bits, com diretrizes importantes, resumidas na Tabela 5.1; mode contm as permisses de acesso associadas ao arquivo. Esse parmetro s obrigatrio para a criao de um arquivo.
A sintaxe do open do UNIX foi ligeiramente alterada, adicionando a opo O_STABLE no parmetro flags. Ao informar este flag, o usurio faz a opo de utilizar o SALIUS na manipulao do arquivo.
O_RDONLY O_WRONLY O_RDWR O_APPEND O_CREAT O_STABLE O_EXCL O_TRUNC O_SYNC O_NOCTTY O_NDELAY
O arquivo aberto apenas para leitura. O arquivo aberto apenas para escrita. O arquivo aberto para leitura e escrita. Todas as escritas iro adicionar dados ao final do arquivo. Se o arquivo existir, no tem efeito algum. Caso contrrio, o arquivo criado e o parmetro mode deve ser especificado. Todas as alteraes do arquivo sero realizadas pelo SALIUS. O arquivo aberto em modo exclusivo. A operao retorna um erro, se o arquivo existir e o O_CREAT estiver prescrito. Se o arquivo existir, seu tamanho truncado para zero. Indica a gravao sncrona de todas as alteraes do arquivo. O Terminal especificado em pathname torna-se o terminal de controle. Afeta todas as leituras e escritas subseqentes. Se uma operao de leitura, ou escrita, no puder ser realizada, retorna, imediatamente, com erro, sem entrar em uma condio de bloqueio.
Tabela 5.1: Flags da operaco open, no SALIUS para UNIX.
68
Semntica: a primitiva open abre o arquivo especificado em pathname, na forma indicada em flags. Se o arquivo no existir e o flag O_CREAT for informado, open realiza a criao do arquivo e armazena, no n-i associado, as permisses de acesso contidas em mode. Normalmente, o arquivo posicionado no incio, mas, se o flag O_APPEND for informado, o apontador da posio corrente inicializado com o tamanho do arquivo. Se o bit O_TRUNC estiver ligado, open ajusta o tamanho do arquivo para zero, liberando todos os blocos de dados. Finalmente, retorna um descritor de arquivos fd para o processo, atravs do qual o processo passa a referenciar o arquivo, nas chamadas de sistema subseqentes. Caso acontea algum erro, open retorna o valor -1 no fd. Quando o O_STABLE informado, todas as operaes de escrita subseqentes realizam o armazenamento estvel, usando a replicao do SALIUS. O_STABLE tambm afeta o comportamento da primitiva open, quando associado aos flags O_CREAT ou O_TRUNC: o open s retorna para a aplicao, quando as alteraes realizadas estiverem estveis, isto , gravadas em disco ou replicadas.
5.4.2 s_creat
A primitiva s_creat a verso estvel do creat original do UNIX, utilizada para criar um arquivo regular, ou rescrever sobre um existente. Sintaxe: fd = s_creat(pathname, mode)
fd um descritor de arquivo, que retorna para a aplicao; pathname o nome de caminho do arquivo; mode contm as permisses de acesso associadas ao arquivo.
Semntica: a primitiva cria um novo arquivo, com o nome indicado em pathname, e armazena as permisses de acesso, informadas em mode, no n-i associado. Se o arquivo existe, s_creat trunca o seu tamanho para zero. Aps ser criado, com sucesso, o arquivo aberto exclusivamente para escrita, com a opo O_STABLE, ou seja, indicando que deve ser alterado de forma estvel. A primitiva s_creat retorna um descritor do arquivo em fd, para uso em outras primitivas, ou retorna o valor -1, caso ocorra algum erro. A primitiva s retorna, aps realizar a replicao, ou gravao em disco dos dados alterados: o superbloco, o n-i do arquivo e do diretrio pai e a entrada do arquivo no diretrio pai.
69
5.4.3 write
A primitiva write utilizada para escrever dados em um arquivo. Sintaxe: num = write(fd, address, nbytes)
fd o descritor do arquivo; address o endereo de uma estrutura, na rea de memria da aplicao, contendo os dados que devem ser escritos no arquivo; nbytes indica o nmero de bytes que devero ser escritos; num retorna com o nmero de bytes gravados.
Semntica: a primitiva write tenta gravar nbytes de um buffer, apontado por adderess, no arquivo associado ao descritor fd. Se a operao for bem-sucedida, retorna em num o nmero de bytes efetivamente gravados, normalmente igual ao valor de nbytes. De outro modo, num retorna com o valor -1, indicando um erro. No retorno, write atualiza o apontador da posio corrente do arquivo, adicionando o nmero de bytes gravados. A primitiva write original adota, como padro, a gravao assncrona de dados. Desse modo, quando write retorna, as modificaes realizadas no arquivo ficam armazenadas na memria principal, em estruturas como a buffer cache, a tabela de ns-i e a cpia do superbloco. Posteriormente, essas mudanas so transferidas para o disco, de forma assncrona. Portanto, o usurio no tem garantias relativas estabilidade dessas informaes, que podem ser apagadas por um crash do sistema. Se o arquivo foi aberto com o bit O_SYNC ligado, write realiza a gravao sncrona de dados, ou seja, s retorna quando todos os dados e metadados do arquivo estiverem gravados em disco. Nesse caso, a aplicao tem a garantia de que as informaes gravadas podem sobreviver a crashes. Se o arquivo for aberto com o flag O_STABLE ligado, ou se for criado atravs da primitiva s_creat, write realiza o armazenamento estvel de dados, ou seja, s retorna aplicao, indicando sucesso, quando ocorre uma das seguintes situaes: as modificaes realizadas no sistema de arquivos esto armazenadas na memria principal e existem cpias dos dados e metadados alterados no Servidor de Replicao de Buffers. Posteriormente, essas mudanas sero transferidas para o disco, como na gravao assncrona; todos os dados e metadados do arquivo, alterados pela operao de escrita, j esto gravados em disco.
70
5.4.4 s_mkdir
Primitiva utilizada para criar um novo diretrio. Sintaxe: s_mkdir(pathname, mode)
pathname o nome de caminho do novo diretrio; mode contm as permisses de acesso ao novo diretrio.
Semntica: a primitiva s_mkdir cria um novo diretrio, com o nome pathname, com as permisses de acesso especificadas em mode. O novo diretrio criado vazio, com exceo das duas entradas, . e .., apontando, respectivamente, para o prprio diretrio e para o diretrio pai. A primitiva s retorna quando os dados alterados estiverem estveis: replicados ou gravados em disco.
5.4.5 s_mknod
A primitiva s_mknod utilizada para criar um arquivo regular, um pipe com nome, um diretrio ou um arquivo especial. Sintaxe: s_mknod(pathname, type-mode, dev)
pathname o nome de caminho do n-i a ser criado; type-mode contm o tipo de arquivo e as permisses de acesso; dev especifica o maior e o menor nmero de dispositivo, para os arquivos especiais.
Semntica: a primitiva cria o arquivo especificado em pathname e armazena o tipo de arquivo e as permisses de acesso, informados em type-mode, no n-i associado. Se o arquivo for especial, de caracter ou blocado, o menor e o maior nmero de dispositivo informados em dev tambm so armazenados no n-i. A primitiva s retorna aps a replicao, ou gravao em disco, dos dados alterados.
5.4.6 s_link
A primitiva s_link cria uma nova entrada de diretrio para um arquivo existente. Sintaxe: s_link(pathname1, pathname2)
pathname1 o nome de caminho do arquivo existente; pathname2 o novo nome de caminho associado ao arquivo.
71
Semntica: a primitiva s_link associa o arquivo indicado por pathname1 ao nome de caminho pathname2, na estrutura de diretrios do sistema de arquivos. Para isso, cria uma nova entrada para o n-i do arquivo, no diretrio indicado em pathname2. A primitiva s retorna aplicao, quando todas as estruturas alteradas no sistema de arquivos estiverem replicadas, ou gravadas em disco.
5.4.7 s_unlink
A primitiva s_unlink utilizada para remover uma entrada de diretrio e/ou excluir um arquivo. Sintaxe: s_unlink(pathname)
pathname o nome de caminho do arquivo existente.
Semntica: a primitiva s_unlink remove a entrada de diretrio indicada em pathname. Quando a ltima entrada de diretrio de um arquivo removida, o arquivo excludo do sistema. Para isso, s_unlink libera todos os blocos de dados do arquivo e o seu n-i. A primitiva s retorna aps a replicao, ou gravao em disco, das alteraes realizadas.
5.4.8 s_chown e s_chmode

Permitem modificar, respectivamente, o proprietrio e as permisses de acesso de um arquivo. Sintaxe: s_chown(pathname, owner, group) s_chmode(pathname, mode) pathname o nome de caminho do arquivo; owner o novo proprietrio de arquivo; group o grupo do novo proprietrio; mode contm as permisses de acesso associadas ao arquivo.
Semntica: as primitivas s_chown e s_chmode alteram informaes armazenadas no n-i do arquivo indicado em pathname. Elas no afetam os blocos de dados do arquivo. A primitiva s_chown passa o direito de propriedade sobre o arquivo para o usurio owner, pertencente ao grupo indicado em group, enquanto s_chmode atribui as permisses de acesso, informadas em mode, ao arquivo. Ambas realizam a replicao do n-i do arquivo.
72
A Tabela 5.2 relaciona as primitivas do SALIUS com as primitivas correspondentes do sistema de arquivos do UNIX e descreve, sucintamente, a funo de cada primitiva.
PRIMITIVA NO UNIX
open write creat mkdir mknod link unlink chown chmode
PRIMITIVA NO SERVIO
Open Write s_creat s_mkdir s_mknod s_link s_unlink s_chown s_chmode
OPERAO
Criao e/ou abertura de um arquivo. Escrita de dados em um arquivo. Criao de um arquivo regular. Criao de um diretrio. Criao de um arquivo de qualquer tipo: regular, diretrio, especial de caracter, especial blocado ou pipe. Criao de uma nova entrada de diretrio para um arquivo existente. Remoo de uma entrada de diretrio de um arquivo existente. Alterao do proprietrio de um arquivo. Alterao das permisses de acesso de um arquivo.
Tabela 5.2: Primitivas do SALIUS.
5.5 Servidor de Arquivos Complementar

O diagrama da Figura 5.2 mostra como ocorre a manipulao de arquivos no UNIX, com a adio do SALIUS. A figura mostra que o SALIUS oferece um servio complementar, implementado por um Servidor de Arquivos Complementar (SAC), o qual incorporado ao sistema de arquivos, assim como as primitivas do SALIUS so acrescentadas interface do sistema. Se um programa de usurio quiser atualizar um arquivo, de forma estvel, basta invocar uma primitiva do SALIUS. O SAC executa uma operao solicitada, interagindo com a buffer cache, para alterar dados na memria, da mesma forma que o sistema de arquivos do UNIX. A seguir, o SAC interage com os drivers de rede para enviar uma mensagem ao SRB, solicitando a replicao dos dados alterados, e receber a confirmao da replicao. O programa de usurio permanece bloqueado, at que a replicao seja confirmada, ou at que o SAC termine de gravar todos dados e metadados alterados no disco, caso ocorra uma falha no servio de replicao, interagindo diretamente com os drivers dos dispositivos de sada.
73
Processos de usurio Primitivas do Unix Nvel do usurio Chamadas do Unix Sistema de arquivos UNIX buffer cache Drivers dos dispositivos de E/S Nvel do ncleo Nvel do hardware Controladores de disco Hardware de disco Drivers de rede Controladores de rede Hardware de rede Chamadas do SALIUS SAC do SALIUS Primitivas do SALIUS
Figura 5.2: Diagrama da manipulao de arquivos no UNIX com SALIUS.
5.5.1 Informaes Replicadas pelo SALIUS

Durante a execuo de cada primitiva do SALIUS, o SAC replica todos os dados alterados, acrescidos de informaes de controle, necessrias ao procedimento de recuperao e ao funcionamento do SRB. Por exemplo, o procedimento de recuperao precisa saber a ordem em que os dados foram gerados, para que possa grav-los no disco nessa mesma ordem, simulando uma repetio das atualizaes realizadas antes de um crash. O procedimento de recuperao tambm precisa saber a posio correta, onde esses dados devem ser gravados no disco. O SRB, por sua vez, precisa estar informado sobre os dados replicados que foram gravados no disco, na mquina do cliente, para que possa descartar a cpia desses dados do seu log e liberar espao na memria principal. O conjunto de informaes de controle depende da implementao do servio. possvel delimitar os dados e metadados do sistema de arquivos que cada primitiva do servio pode vir a alterar. A Tabela 5.3 relaciona cada primitiva do servio com o seu conjunto de dados alterveis. Na primeira linha, esto agrupadas todas as primitivas do servio. Na primeira coluna, esto relacionados todos os dados e metadados que podem ser alterados. num sistema de arquivos. Em cada uma das demais colunas, existe um X nas linhas que contm dados ou metadados sujeitos a alteraes pelas primitivas listadas no cabealho da coluna.
74
PRIMITIVAS DO SERVIO DE ARMAZENAMENTO ESTVEL DADOS REPLICADOS

Superbloco N-i de arquivo Blocos de dados de arquivo N-i do diretrio pai Bloco de dados do dir. pai open s_creat write s_mkdir s_mknod s_link s_unlink s_chown s_chmod
X X X X
X X X
X X X X X
X X X X X
Tabela 5.3: Dados replicados pelas primitivas do SALIUS.
O superbloco pode ser alterado por quase todas as primitivas do servio, porque ele contm um sumrio de informaes sobre o sistema de arquivos. As mudanas no estado do sistema, em geral, modificam essas informaes. Por exemplo, qualquer alterao que implique na alocao ou na liberao de blocos de dados, ou de ns-i, tambm altera o superbloco, porque ele contm a lista de ns-i livres, o incio da lista de blocos livres e contadores com o nmero de ns-i livres e o nmero de blocos livres. O n-i de um arquivo pode ser alterado por todas as primitivas do servio: a adio e remoo de blocos de dados pode alterar a tabela de endereos armazenada no n-i; as operaes de criao de arquivos e diretrios alocam um n-i para o novo arquivo; operaes de criao e remoo de entradas de diretrio alteram o contador de referncias do n-i; certos atributos do arquivo, armazenados no n-i, podem ser explicitamente alterados, como o proprietrio e as permisses de acesso. Algumas primitivas alteram blocos de dados de um arquivo. A primitiva write sempre altera um ou mais blocos de dados. As primitivas s_mknod e s_mkdir tambm alteram blocos de dados, quando esto criando um diretrio, pois gravam, no primeiro bloco de dados do diretrio, as entradas contendo, respectivamente, o n-i do prprio diretrio e o n-i do diretrio pai. Certas primitivas alteram dados do diretrio pai de um arquivo, criando ou removendo entradas de diretrio para o arquivo. So as primitivas utilizadas para criar um novo arquivo, como s_creat, open, s_mkdir e s_mknod, ou primitivas que manipulam diretamente as entradas de diretrio, como s_link e s_unlink. Muitas vezes, essas alteraes exigem que novos blocos de dados sejam alocados para o diretrio pai, que aumenta de tamanho, alterando, conseqentemente, o n-i desse diretrio.
75
Nem sempre uma primitiva altera todos os dados contidos no conjunto a ela associado. A primitiva write, por exemplo, sempre altera blocos de dados. Porm, somente em algumas situaes um write precisa alterar o superbloco. A seguir, sero apresentados os dados alterados pelas primitivas s_creat, open e write. O Apndice A contm uma anlise dos dados alterados por todas as primitivas do SALIUS.
5.5.1.1 Informaes replicadas pela primitiva s_creat

A primitiva s_creat utilizada para criar um arquivo. Ela aloca um n-i para o novo arquivo. Para isso, retira um n-i da lista de ns-i livres. Conseqentemente, a primitiva altera o superbloco, onde a lista de ns-i livres est armazenada e onde existe um contador de ns-i livres, que decrementado quando o n-i alocado. A primitiva tambm cria uma entrada para o n-i do arquivo no diretrio pai, alterando um bloco de dados desse diretrio. Se o tamanho do diretrio pai aumentar, a primitiva ajusta o tamanho de arquivo, armazenado no n-i desse diretrio. Se o ltimo bloco de dados do diretrio pai estiver cheio, a primitiva s_creat deve alocar um novo bloco para armazenar a entrada do arquivo, retirando um bloco da lista de blocos livres e alterando o contador de blocos livres, no superbloco. A primitiva s_creat precisa replicar todas as estruturas alteradas durante a sua execuo, o que pode consistir de: o superbloco, o n-i do novo arquivo, o n-i do diretrio pai e o bloco de dados do diretrio pai, com a entrada do novo arquivo.
5.5.1.2 Informaes replicadas pela primitiva open

A primitiva open abre um arquivo existente e pode criar um novo arquivo, caso o flag O_CREAT seja informado. No caso da criao de um arquivo, os dados que devem ser replicados so os mesmos da primitiva s_creat. Quando um arquivo existente aberto, normalmente, nenhum dado alterado, com exceo da situao em que o flag O_TRUNC informado. Nesse caso, todos os blocos do arquivo so liberados e a primitiva altera o n-i do arquivo, ajustando o tamanho do arquivo para zero. A operao de truncamento do arquivo tambm afeta o superbloco, pois os blocos liberados so inseridos na lista de blocos livres e o tamanho dessa lista incrementado. Assim, a primitiva open, quando invocada com a opo O_TRUNC, deve replicar o n-i do arquivo e o superbloco.
76
5.5.1.3 Informaes replicadas pela primitiva write

A primitiva write utilizada para escrever dados em um arquivo. Quando uma aplicao invoca essa primitiva, ela passa, como parmetro de entrada, um buffer de usurio contendo os dados a serem alterados. A primitiva deve replicar os dados informados, bem como a posio no arquivo, onde deve iniciar a gravao desses dados. Essa posio lida na tabela de arquivos abertos. Se o arquivo tiver sido previamente aberto com a opo O_APPEND, significa que os dados sero acrescidos ao final do arquivo, aumentando o seu tamanho. Nesse caso, a primitiva ajusta o tamanho do arquivo, no seu respectivo n-i. Quando o tamanho de um arquivo aumenta, novos blocos precisam ser alocados, alterando a lista de blocos livres e o superbloco. Desse modo, a primitiva write pode precisar replicar tambm o superbloco e o n-i do arquivo.
5.6 Procedimento de Recuperao

Essa seo apresenta a especificao do ltimo componente do SALIUS: um procedimento de recuperao de crash. O servio considera a ocorrncia de um crash toda vez que as estruturas de dados do sistema de arquivos, residentes em memria, so perdidas. A recuperao de crash o ato de restaurar o sistema de arquivos em disco para um estado consistente, de modo que preserve as garantias oferecidas pelo servio s aplicaes: o SALIUS assegura a estabilidade de todos os dados armazenados atravs de suas primitivas. De forma genrica, os mecanismos de recuperao podem ser divididos em duas grandes classes: recuperao para frente e recuperao para trs. Quando ocorre um crash, os efeitos de algumas operaes podem estar apenas parcialmente refletidos no sistema de arquivos, deixando o mesmo num estado inconsistente. Um procedimento de recuperao tem a funo de levar o sistema de arquivos para um estado consistente. Se esse estado for anterior ocorrncia do crash, diz-se que o sistema se recuperou para trs. Para isso, os efeitos das operaes parcialmente registradas so desfeitos. Na recuperao para frente, pelo contrrio, as operaes parcialmente registradas so finalizadas. Os efeitos dessas operaes so inteiramente refletidos no sistema de arquivos, levando-o a um estado consistente posterior ao crash. A recuperao para frente conseguida atravs de um mecanismo de repetio das operaes executadas at o momento imediatamente anterior ao crash: partindo-se do pressuposto de que, inicialmente, o sistema de arquivos est consistente e guardando-se os resultados de todas as operaes realizadas durante o funcionamento normal do sistema, para colocar o disco num estado consistente, aps um crash, basta gravar os resultados das operaes no disco, exatamente na ordem em que foram gerados, simulando uma repetio das operaes.
O mecanismo de recuperao do SALIUS se enquadra na classe de recuperao para frente: todos os dados e metadados atualizados no sistema de arquivos, que so perdidos em decorrncia de um crash, permanecem guardados no Servidor de Replicao de Buffers; o mecanismo de recuperao obtm esses dados e providencia a grav-los no disco, na mesma ordem em que foram gerados. Assim, o mecanismo de recuperao do SALIUS garante a durabilidade dos efeitos de operaes realizadas antes do crash. A seguir, sero apresentados, em detalhes, os possveis estados das estruturas de dados do sistema de arquivos, na ocasio de um crash, e as solues asseguradas pelo mecanismo de recuperao do SALIUS.
5.6.1 Efeitos do Procedimento de Recuperao

As situaes descritas neste item ilustram os efeitos causados pelo procedimento de recuperao do SALIUS, sobre as estruturas de dados do sistema de arquivos . Suponha a ocorrncia de um crash no tempo t1, com o sistema de arquivos no estado representado pela Figura 5.3. O crash provoca a destruio de todo o contedo do sistema de arquivos mantido na memria e ainda no gravado em disco.
t1
S
n1 n2 n3 n4
Superbloco Tabela de Ns-i
S
sb n1 b2 n2 b3 n3 b4 n4 b5
b1
b2 b3 b4 Buffer Cache
b5
b1
Estruturas na memria Dado no alterado Dado alterado por uma primitiva do SALIUS
Estruturas no disco
Dado alterado por uma chamada de sistema original do Unix
Figura 5.3: Estado de um sistema de arquivos na ocasio de um crash.
78
Nas figuras desta seo, constam os componentes de um sistema de arquivos UNIX, em disco: o superbloco, os ns-i e os blocos de dados. O sistema realiza caching de tais componentes, com o objetivo de diminuir a quantidade de acessos a disco. Na memria, esses dados ficam armazenados em estruturas auxiliares: o superbloco copiado para um superbloco auxiliar, o contedo dos blocos de dados carregado na buffer cache, enquanto os ns-i so carregados na tabela de ns-i. Todas as figuras foram configuradas de forma didtica: na estrutura real de um sistema de arquivos em disco, normalmente, existe um nmero bem maior de ns-i e de blocos de dados, que no precisam estar armazenados contiguamente, nem de forma ordenada. As figuras exibem possveis estados dos dados mantidos em memria: os componentes em branco esto com o mesmo contedo lido do disco, significando que no sofreram alteraes; os componentes hachurados foram alterados, atravs de chamadas de sistema originais do sistema de arquivos do UNIX; os componentes em preto foram atualizados por primitivas do SALIUS. Na Figura 5.3, por exemplo, alguns dados modificados j foram gravados em disco, tornando-se, portanto, estveis: n-i n2 e blocos b2 e b4. Porm, a maioria das alteraes foi realizada apenas na memria. Na hiptese de no acontecer o crash e do sistema de arquivos permanecer inacessvel para atualizaes, durante um certo perodo, existir um tempo t2, quando todos os dados alterados na memria estaro estveis. Isso porque os sistemas de arquivos do UNIX gravam todos os dados no disco, periodicamente. O perodo entre as gravaes pode variar de um sistema de arquivos para outro, mas, em geral, no ultrapassa os trinta segundos.
t2
S
n1 n2 n3 n4
S
sb n1 b2 n2 b3 n3 b4 n4 b5
b1
b5
b1
Estruturas no disco
Dado alterado por uma chamada de sistema original do Unix Figura 5.4: Sistema de arquivos da Figura 5.3, aps gravao dos dados.
A Figura 5.4 ilustra o estado do sistema de arquivos da Figura 5.3, no tempo t2, com todas as alteraes j gravadas em disco. Assim, o contedo dos componentes de dados na memria idntico aos seus respectivos contedos no disco. Na hiptese do crash realmente acontecer em t1, o SALIUS deve garantir que, num tempo t3, aps a execuo do procedimento de recuperao, o sistema de arquivos contenha todos os dados gravados em disco, antes do crash, acrescidos dos dados alterados, em memria, pelas primitivas do servio.
t3
S
n1 n2 n3 n4
S
sb n1 b2 n2 b3 n3 b4 n4 b5
b1
b5
b1
Estruturas na memria antes do crash
Estruturas no disco aps recuperao
Figura 5.5: Sistema de arquivos da Figura 5.3, aps a recuperao.
O sistema de arquivos, que se encontrava no estado apresentado pela Figura 5.3, antes do crash, levado para o estado apresentado na Figura 5.5, pelo mecanismo de recuperao do SALIUS. Note-se que o n-i n2 e os blocos de dados b2 e b4 j se encontravam estveis na ocasio do crash. O procedimento de recuperao do servio restaura, a partir de uma rplica, os dados em preto, ou seja, armazenados pelas primitivas do servio: o superbloco, o n-i n4 e os blocos b2 e b5. importante ressaltar que os dados armazenados pelas primitivas originais do sistema de arquivos do UNIX, e ainda no gravados em disco, so perdidos com o crash: o n-i n3 e o bloco b3. As Figuras 5.3, 5.4 e 5.5, apresentadas, ilustram a idia bsica que norteia o mecanismo de recuperao do SALIUS. Na prtica, entretanto, existem situaes mais complexas. Durante a permanncia de um item de dado na memria, ele pode sofrer vrias alteraes consecutivas, antes de ser gravado em disco. Algumas alteraes podem envolver apenas parte do contedo de um item.
As figuras seguintes expem uma situao mais abrangente, onde aparecem itens cujos contedos foram apenas parcialmente alterados, ora por primitivas do SALIUS, ora por chamadas de sistema originais do sistema de arquivos do UNIX.
t1
n1 n2 S n3 n4 Superbloco Tabela de Ns-i sb b1 b6 b2 b7 b3 b8 b4 b5 b9 b10
n1 b2 b7
n2 b3 b8
n3 b4
n4 b5
b1 b6
Buffer Cache
b9 b10
Estruturas no disco
Dado alterado por uma chamada de sistema original do UNIX Figura 5.6: Estado de um sistema de arquivos na ocasio de um crash.
A Figura 5.6 apresenta um sistema de arquivos na ocasio de um crash. Os dados exibidos esto nos seguintes estados: o n-i n1 e o bloco b1 foram carregados na memria e permanecem inalterados; o superbloco, o n-i n4 e o bloco de dados b8 foram alterados atravs de primitivas do SALIUS e ainda no foram gravados no disco; o bloco b2 foi atualizado por uma primitiva do SALIUS e j foi gravado em disco; parte do contedo do n-i n3 e o bloco b3 foram atualizados por chamadas de sistema originais do sistema de arquivos do UNIX e essas alteraes ainda no foram propagadas para o disco; o n-i n2 e o bloco b9 foram atualizados por chamadas de sistema originais do sistema de arquivos do UNIX e j foram gravados em disco; apenas uma parte do contedo do bloco b4 foi atualizada por uma chamada de sistema original do UNIX. A alterao ainda no foi propagada para o disco;
81
apenas uma parte do contedo do bloco b5 foi atualizada por uma primitiva do SALIUS. A alterao ainda no foi propagada para o disco; o bloco b6 sofreu duas alteraes consecutivas. Primeiro, o seu contedo foi atualizado por uma chamada de sistema do UNIX e o bloco foi gravado em disco. A seguir, apenas uma parte do bloco foi alterada pelo SALIUS e os efeitos dessa operao ainda no foram refletidos no disco; o bloco b7 pode ser dividido em trs partes. Uma poro inicial foi atualizada pelo SALIUS. A segunda parte do bloco permaneceu inalterada, enquanto o restante do contedo do bloco foi modificado por uma chamada de sistema do UNIX. As alteraes ainda no foram propagadas para o disco; uma parte do bloco b10 foi atualizada por uma chamada de sistema do UNIX e outra parte, pelo SALIUS. As alteraes j foram gravadas em disco.
A Figura 5.7 ilustra a situao do sistema de arquivos apresentado pela Figura 5.6, num estado completamente estvel. Esse estado pode ser conseguido num tempo t2, aps a gravao de todos os dados no disco, caso o sistema permanea operacional e no sofra alteraes no perodo entre t1 e t2. Nesse caso, todas as alteraes so refletidas no sistema de arquivos em disco.
t2
S
n1 n2 n3 n4
S
sb n1 b2 b7 n2 b3 b8 n3 b4 n4 b5
b1 b6
b2 b7
b3 b8
b4
b5
b1 b6
b9 b10
b9 b10
Buffer Cache
Estruturas no disco
Dado alterado por uma chamada de sistema original do Unix Figura 5.7: Sistema de arquivos da Figura 5.6, aps gravao dos dados.
82
A Figura 5.8 apresenta a situao do sistema de arquivos da Figura 5.6, no tempo t3, aps a recuperao de um crash, ocorrido no tempo t1. Note-se que apenas os dados armazenados pelas primitivas do SALIUS foram recuperados.
t3
S
n1 n2 n3 n4
S
sb n1 b2 b7 n2 b3 b8 n3 b4 n4 b5
b1 b6
b2 b7
b3 b8
b4
b5
b1 b6
b9 b10
b9 b10
Buffer Cache
Estruturas no disco aps recuperao
Figura 5.8: Sistema de arquivos da Figura 5.6, aps a recuperao.
5.6.2 Restaurao do Sistema de Arquivos

O procedimento de recuperao do SALIUS interage com o SRB, solicitando os dados replicados antes do crash. Ao obter os dados replicados, o procedimento de recuperao providencia grav-los no disco, exatamente na ordem em que foram gerados. As mensagens de replicao contm informaes de controle, indicando a ordem em que as atualizaes do sistema de arquivos aconteceram. Por exemplo, a implementao do SALIUS pode englobar um contador de pedidos de replicao, nico para cada sistema de arquivos. Assim, toda vez que o SAC executa uma operao de atualizao, o contador incrementado e o nmero do pedido enviado na mensagem de replicao, para o SRB. Quando o procedimento de recuperao obtm as mensagens de replicao de volta, ele ordena os dados recuperados pelo nmero do pedido, antes de iniciar a gravao em disco. Como o procedimento de recuperao realiza as atualizaes na mesma ordem na qual elas foram originalmente realizadas, a operao de recuperao idempotente. Assim, caso ocorra um crash durante a recuperao, seja na rplica utilizada para fornecer os dados da recuperao, seja na mquina onde o sistema de arquivos reside, o procedimento pode ser repetido: mesmo que a recuperao j tenha sido parcialmente realizada, o sistema de arquivos sempre chega ao mesmo estado final.
A Figura 5.9 exibe o mesmo sistema de arquivos da Figura 5.3, no momento da ocorrncia de um crash, incluindo as informaes j replicadas. O crash provoca a destruio de todos os dados armazenados na memria principal. Alguns dados j se encontram gravados em disco: o n-i n2 e os blocos b2 e b4. Algumas estruturas foram replicadas: o superbloco, o n-i n4 e os blocos b2 e b5.
n1 n2 n3 n4
S Superbloco
n4
S
sb n1 b2 n2 b3 n3 b4 n4 b5
Tabela de Ns-i Buffer Cache
b1
b5
b1
b2
b5
Estruturas no Disco antes do crash
Estruturas Replicadas
Figura 5.9: Sistema de arquivos antes do crash.
A Figura 5.10 mostra como o procedimento de recuperao do SALIUS restaura o sistema de arquivos: l os dados armazenados na rplica de recuperao e, a seguir, grava os dados recuperados no disco.
S Superbloco
n4 Tabela de Ns-i Buffer Cache
Recuperao
S
sb b1 n1 b2 n2 b3 n3 b4 n4 b5
b2
b5
Rplica de Recuperao
Disco aps Recuperao
Figura 5.10: Restaurao do sistema de arquivos da Figura 5.9.
84
5.6.3 Situao Atpica

Existe uma situao especial, que merece ser considerada pelo mecanismo de recuperao. Tal situao est ilustrada na Figura 5.11, que foi dividida em cinco partes, cada uma delas apresentando um momento diferente do sistema de arquivos. No primeiro momento t1, um bloco de dados foi atualizado e replicado por uma primitiva do SALIUS. No tempo t2, uma parte do contedo do bloco foi atualizada por uma chamada de sistema original do UNIX (parte hachurada). Em t3, o bloco foi gravado no disco e a cpia replicada tornou-se desatualizada. Em t4, ocorreu um crash e o contedo da memria foi perdido. Em t5, o procedimento de recuperao do SALIUS foi ativado e gravou no disco o bloco obsoleto, enviado pelo Servidor de Replicao de Buffers, sobrepondo uma atualizao mais recente. A situao retratada rara e pode ser evitada, se a implementao do Servidor de Replicao de Buffers puder impedir a manuteno de blocos obsoletos.
t1 Memria Disco Rplica
t4
crash Memria Disco Rplica
t5 Rplica
Recuperao Disco
Figura 5.11: Situao especial na recuperao de um crash.

5.6.4 Recuperao de Dados Gravados por Primitivas do UNIX

O mecanismo de recuperao do SALIUS assegura, nica e exclusivamente, a recuperao de dados armazenados atravs de primitivas do servio. Ele no trata os dados armazenados pelas primitivas tradicionais do sistema de arquivos. Para esse subconjunto de dados, devem ser utilizados os procedimentos de recuperao oferecidos pelo prprio sistema de arquivos. Como foi descrito com detalhes, no Captulo 2, o UNIX utiliza um programa de recuperao, denominado fsck, para remover inconsistncias do sistema de arquivos. O fsck continua sendo necessrio, para o subconjunto de dados armazenado com as primitivas originais do UNIX.
5.6.5 Desempenho do Mecanismo de Recuperao do SALIUS

Para o subconjunto de dados armazenados pelo SALIUS, a recuperao de crash potencialmente muito rpida. No necessrio realizar verificaes na estrutura de metadados do sistema, porque todos os metadados afetados numa determinada operao so automaticamente replicados, junto com os dados alterados. Se a implementao do Servidor de Replicao de Buffers puder impedir a situao atpica relatada em 5.6.3, ento, tambm ser capaz de fornecer sempre a verso mais atualizada dos dados e metadados do sistema de arquivos. Nesse caso, a recuperao resume-se em obter os dados replicados antes do crash e grav-los no disco.
5.7 Consideraes sobre Desempenho e Confiabilidade

Esta seo tem como objetivo demonstrar que o desempenho e a estabilidade, providos pelo SALIUS, dependem fundamentalmente da tecnologia utilizada e da implementao do Servio de Replicao de Buffers.
5.7.1 Influncias da Tecnologia

Todo o funcionamento do SALIUS est diretamente vinculado tecnologia de rede e tecnologia de memria. Os principais fatores da tecnologia que influenciam no desempenho e na capacidade de prover estabilidade de dados do SALIUS so: A velocidade de acesso memria principal. Como todas as operaes providas pelo servio atualizam dados na memria principal e a replicao transfere dados da memria de uma mquina para outra, quanto maior a velocidade de acesso memria, melhor ser o desempenho do sistema.
86
A confiabilidade da memria principal. Quanto mais confivel o armazenamento em memria, menores as chances de um dado da memria ser destrudo, aumentando a probabilidade de manter as informaes estveis. A quantidade de memria principal disponvel. Quanto maior a capacidade da memria principal das mquinas do sistema, maior a quantidade de dados que podem ser mantidos na cache e replicados. A falta de memria pode tornar a replicao impossvel, levando o SALIUS a realizar gravaes sncronas e degradando, assim, o desempenho do sistema. Com uma grande disponibilidade de memria, o SALIUS pode realizar a replicao com xito. Adicionalmente, pode-se aumentar o intervalo de tempo no qual os dados alterados permanecem na cache, contribuindo para diminuir a quantidade de operaes de escrita em disco e melhorando o desempenho do sistema. A taxa de transmisso de dados atravs da rede. Quanto maior a taxa de transmisso de dados na rede, mais rpida ser a replicao, diminuindo o tempo de resposta das aplicaes que usam o servio e aumentando o desempenho do sistema. A confiabilidade do meio de transmisso de dados. Quanto mais confivel for o meio de transmisso de dados, menores as chances de mensagens perdidas ou corrompidas, aumentando a probabilidade de manter as informaes estveis. A replicao torna-se mais rpida, porque diminui a quantidade de retransmisses de mensagens, aumentando o desempenho. Adicionalmente, crescem as chances de sucesso da replicao, diminuindo a necessidade de gravaes sncronas, o que tambm contribui para um melhor desempenho do sistema. A banda passante da rede. Quanto maior a banda passante da rede utilizada pelo servio, menor a probabilidade do trfego gerado causar um congestionamento. Um congestionamento pode causar uma falha de tempo no Servio de Replicao de Buffers, levando o SALIUS a realizar gravaes sncronas. Por isso, aumentando a banda passante da rede, crescem as chances de sucesso das operaes de replicao, contribuindo para um melhor desempenho do sistema.
importante frisar que o trfego na rede um fator crucial ao desempenho do SALIUS. Toda a operao do SALIUS envolve a troca constante de mensagens atravs da rede. Um alto trfego na rede, pode tornar-se um gargalo ao desempenho do servio, ou chegar a inviabilizar o seu funcionamento. Portanto, quanto melhor a estrutura de rede e a memria principal utilizadas pelo sistema, melhor o desempenho e a confiabilidade do SALIUS. Quando os componentes de hardware utilizados possibilitam o funcionamento pleno do SALIUS, com a realizao bem-sucedida da replicao, a gravao dos dados em disco realizada de forma assncrona. Enquanto o sistema est gravando buffers da cache, a aplicao continua o seu processamento e o SALIUS atende a outras requisies.
O tempo de processamento de uma primitiva do SALIUS depende do tempo de replicao dos dados: a aplicao no espera pela gravao em disco, a menos que ocorra uma falha no Servio de Replicao de Buffers. Por isso, quando todos os componentes do SALIUS esto funcionando corretamente, a influncia do tempo de acesso a disco no desempenho global do sistema minimizada. O desempenho do sistema passa a depender muito mais da tecnologia de memria e da tecnologia de rede. Adicionalmente, quanto melhor a estrutura de rede e a tecnologia de memria utilizadas, maiores as chances de sucesso da replicao e maior a probabilidade de garantir a estabilidade das informaes, aumentando a confiabilidade do SALIUS.
5.7.2 Influncias do Servio de Replicao de Buffers

O SALIUS no depende apenas da tecnologia para conseguir alcanar os objetivos estabelecidos. O sucesso do SALIUS est subordinado a uma implementao eficiente dos seus componentes, especialmente do Servio de Replicao de Buffers, o seu componente vital. O processamento de qualquer primitiva do SALIUS utiliza o Servio de Replicao de Buffers. Ao executar uma operao solicitada, o SAC espera receber uma mensagem de confirmao da replicao, ou detectar uma falha no SRB, antes de retornar o controle ao cliente. Portanto, quanto mais rpida a replicao, melhor o desempenho do sistema. A rapidez de uma operao de replicao depende da forma como o Servio de Replicao de Buffers est implementado. Alm do desempenho, a confiabilidade do SALIUS tambm depende da implementao do Servio de Replicao de Buffers. Quando uma mensagem de confirmao de uma replicao retorna, o SAC assume que os dados j esto sendo mantidos de forma confivel pelo SRB. Por isso, o SAC retorna o controle para a aplicao, garantindo a estabilidade das informaes. Porm, a probabilidade do SALIUS conseguir manter, realmente, a estabilidade dos dados armazenados, deriva da probabilidade do Servio de Replicao de Buffers manter estvel uma informao, para a qual uma confirmao foi enviada ao SAC. Portanto, a implementao do Servio de Replicao de Buffers influencia tanto no desempenho, quanto na confiabilidade do SALIUS. Normalmente, estes dois requisitos so conflitantes, ou seja, priorizar um implica no detrimento do outro. Por exemplo, uma soluo trivial seria no existir um SRB executando. Assim, o cliente nunca receberia uma mensagem de confirmao e realizaria sempre a gravao sncrona das informaes. A vantagem seria a alta confiabilidade do servio, ou seja, nunca poderia existir uma mensagem de confirmao de replicao errada. Deste modo, toda vez que o SALIUS confirmasse o sucesso de uma operao para um programa de usurio, os dados alterados estariam, de fato, gravados em disco. Porm, essa soluo no atende a um dos principais objetivos do servio, que justamente melhorar o seu desempenho em relao s solues tradicionais, baseadas em escritas sncronas.
Uma segunda implementao bastante simples seria um SRB executando em uma nica mquina da rede local, ligada a um no-break. Nesse caso, o desempenho seria priorizado: a replicao poderia ser muito rpida, pois o cliente s estaria enviando dados e recebendo a confirmao de um nico SRB. No entanto, a confiabilidade do servio seria sacrificada, pelo fato do SRB no ser tolerante a crashes no sistema operacional. Uma variao da segunda soluo apresentada seria a implementao de um SRB executando numa nica mquina, ligada ao servidor de arquivos por um barramento de alta velocidade. Neste caso, o desempenho seria ainda maior, devido comunicao veloz provida pelo barramento. Entretanto, a confiabilidade oferecida seria limitada, pelo fato de haver apenas uma rplica de dados. A implementao de um Servio de Replicao de Buffers deve balancear, da melhor forma possvel, o atendimento aos requisitos de desempenho e confiabilidade. No prximo captulo, ser apresentado um projeto para o Servio de Replicao de Buffers, que busca um equilbrio no atendimento a esses requisitos.
89
Captulo 6
6 Projeto de um Servio de Replicao de Buffers
Este captulo apresenta um projeto de um Servio de Replicao de Buffers para o SALIUS. Inicialmente, so especificados os requisitos do servio. A seguir, o projeto detalhado, com a descrio da utilizao de um grupo de rplicas na implementao do servio e a apresentao do modelo de replicao adotado. As rplicas que implementam o SRB interagem entre si, e com os clientes, de acordo com um protocolo de replicao. Em tais interaes, a comunicao tambm obedece a um protocolo. Este captulo descreve o protocolo de comunicao utilizado e detalha as operaes e os algoritmos do protocolo de replicao do Servio de Replicao de Buffers.
6.1 Requisitos do Servio de Replicao de Buffers

O Servio de Replicao de Buffers do SALIUS precisa atender a dois requisitos, normalmente conflitantes: a) enviar a mensagem de confirmao de um pedido de replicao, o mais rapidamente possvel, e b) ter uma alta probabilidade de manter estvel uma informao, para a qual uma mensagem de confirmao foi enviada a um cliente. Para conseguir atender aos requisitos de desempenho, o Servio de Replicao de Buffers deve utilizar a estrutura de uma rede local: quanto maior a velocidade da rede, melhor ser o desempenho do servio. A garantia da estabilidade das informaes armazenadas depende do grau de tolerncia a faltas do servio: a implementao de um servio, atravs de um grupo de rplicas, uma forma de prover tolerncia a faltas.
Captulo 6 Projeto de um Servio de Replicao de Buffers 90
6.2 Grupo de Rplicas

O Servio de Replicao de Buffers implementado atravs de um processo, denominado Servidor de Replicao de Buffers (SRB), executando em vrias mquinas do sistema distribudo. Em cada mquina, o SRB realiza o mesmo processamento: recebe e armazena os dados replicados na execuo das primitivas do SALIUS e interage com o mecanismo de recuperao, para fornecer os dados necessrios restaurao da consistncia do sistema de arquivos. Como o servio oferecido exatamente o mesmo, em todas as mquinas, os processos servidores so denominados rplicas uns dos outros. Uma maneira de gerenciar rplicas considerar cada rplica individual como um membro de um grupo de rplicas. A funcionalidade geral de grupos, em sistemas distribudos, est descrita no projeto ANSA1 [ANS90] [ANS91] e em artigos tcnicos [LCN90] [OOW91]. Tambm existem previses de que o servio de replicao ser adicionado s especificaes CORBA2 [OMG95] [Bir96]. As rplicas do Servidor de Replicao de Buffers so agrupadas por vrias razes: como uma forma de abstrair as caractersticas comuns dos membros do grupo e do servio de replicao que eles oferecem; para encapsular os estados internos e as interaes entre os membros do grupo, de forma a prover o usurio de uma interface uniforme, a interface de grupo, contribuindo, assim, para que o servio atenda ao requisito de transparncia; com o intuito de delimitar as mquinas que armazenam cpias dos dados de um cliente, racionalizando o uso de recursos do sistema.
Portanto, o Servio de Replicao de Buffers do SALIUS provido por um grupo de rplicas. Os clientes desse servio so de dois tipos: um Servidor de Arquivos Complementar (SAC), que requisita a replicao de informaes, e um Procedimento de Recuperao, que requisita as informaes necessrias para restaurar o sistema de arquivos a um estado consistente, mantendo estveis as informaes armazenadas atravs de primitivas do SALIUS.
ANSA (Advanced Network Systems Architecture), um projeto britnico, liderado por Andrew Herbert, que constituiu a primeira tentativa sistemtica de desenvolver tecnologia para modelar sistemas distribudos complexos. Consiste de um conjunto de modelos que tratam de vrios aspectos de projeto de sistemas distribudos, com um enfoque de orientao a objetos. 2 CORBA (Common Object Request Broker Architecture), um projeto posterior ao ANSA, iniciado por um consrcio de fabricantes de computadores, que tem como objetivo definir padres avanados para conseguir a interoperabilidade de sistemas distribudos complexos, orientados a objetos, construdos por fabricantes diferentes. CORBA define padres para um grande conjunto de servios. CORBA basicamente um molde para construo de sistemas distribudos e tornou-se uma tendncia. Captulo 6 Projeto de um Servio de Replicao de Buffers 91
6.1.1 A Composio do Grupo de Rplicas

O nmero de rplicas participantes do grupo definido de acordo com o grau de tolerncia a faltas desejado e da semntica de falha do servio. Quando um sistema adota uma semntica de falha por crash, o grupo deve ser formado de k rplicas, sendo k f + 1, para que seja possvel tolerar f faltas [Cri91]. No SALIUS, o cliente tambm mantm uma cpia dos dados alterados no sistema de arquivos. Por isso, uma rplica mantida no cliente, enquanto as demais n rplicas compem o grupo do SRB ( n = k 1 n f ). Assim, se f mquinas sofrerem crashes simultneos, restar, pelo menos, uma mquina operacional contendo a cpia dos dados alterados que devem permanecer estveis. A composio ideal do grupo de rplicas voltar a ser discutida na seo 6.7, quando sero considerados alguns detalhes da implementao. Cada pedido de replicao do SAC precisa ser confirmado por r rplicas, sendo r = f, para que a replicao seja considerada bem-sucedida: se o SAC no receber mensagens de, pelo menos, r rplicas distintas, confirmando o recebimento de um pedido de replicao, num tempo mximo predefinido, ento o SAC assume que o SRB falhou. Sendo n o nmero de rplicas, f o nmero de faltas tolerado e r o nmero de rplicas que respondem a um pedido, o SRB pode falhar em duas situaes distintas: a) quando n - freal < f , sendo freal o nmero real de replicas que sofreram crash; ou b) quando ocorre um particionamento (real ou virtual) entre o cliente e o grupo de rplicas, ou seja, quando o servio de comunicao falha, temporariamente, impedindo que o SAC envie pedidos e/ou receba mensagens de confirmao de r rplicas.
6.1.2 A Consistncia das Rplicas

O Servio de Replicao de Buffers precisa manter a consistncia das rplicas operacionais, isto , todas as rplicas que respondem aos pedidos de replicao devem permanecer atualizadas, para que seja possvel assegurar a estabilidade das informaes armazenadas atravs do SALIUS. Quando n > f, mesmo que todas as operaes de replicao sejam realizadas com sucesso, algumas rplicas podem ficar desatualizadas: uma falha do servio de comunicao pode impedir que algumas das rplicas recebam um pedido de replicao, muito embora outras r rplicas do grupo consigam atender ao pedido, enviando mensagens de confirmao ao cliente. Nesse caso, o SAC recebe r mensagens de confirmao para um pedido de replicao, mas algumas rplicas do grupo no contm os dados daquele pedido.
Captulo 6 Projeto de um Servio de Replicao de Buffers
92
Se cada pedido de replicao for recebido por um conjunto diferente de rplicas, aps um crash no cliente, o grupo de rplicas pode estar em situaes que dificultam, ou que impossibilitam a recuperao do sistema de arquivos, tais como: a) nenhuma rplica contm todos os pedidos de replicao, enviados antes do crash, ou b) alguns pedidos foram irremediavelmente perdidos, devido a falhas anteriores, justamente nas nicas rplicas que armazenavam aquele pedido. Na situao a, ainda possvel recuperar o sistema de arquivos: basta que o procedimento de recuperao faa um merge das informaes armazenadas nas diversas rplicas. Contudo, na situao b, a recuperao de todas as informaes armazenadas antes do crash impossvel. O servio precisa garantir que, no mnimo, r rplicas, sendo r = f, permanecem sempre atualizadas: caso ocorram f crashes simultneos, nas mquinas do sistema, envolvendo, inclusive, a mquina que executa o sistema de arquivos, restar, pelo menos, uma rplica com todas as informaes necessrias para manter a estabilidade dos dados armazenados antes do crash. Todo o funcionamento de um grupo de rplicas ordenado atravs de um protocolo de replicao, inclusive as aes realizadas para manter a consistncia das rplicas. Este protocolo especifica como sero as interaes entre os clientes e os grupos, e entre os membros que compem um grupo. O protocolo de replicao depende do modelo de replicao e do protocolo de comunicao utilizados, que sero apresentados a seguir.
6.2 Modelo de Replicao

Existem duas formas bsicas de realizar replicao: replicao passiva e replicao ativa [Lit92]. Ambas podem ser usadas para mascarar falhas por crash em sistemas distribudos. No entanto, cada classe de replicao tem uma maneira peculiar de tratar uma rplica individual e um grupo de rplicas.
6.2.1 Replicao Passiva

Na replicao passiva, ilustrada pela Figura 6.1, s existe um membro ativo no grupo de rplicas, denominado membro primrio, que recebe (fluxo1) e executa as requisies de clientes. Durante o processamento de uma requisio, o membro primrio realiza checkpoints peridicos, ou seja, propaga as mudanas no seu estado para os membros passivos, preservando a consistncia entre os membros do grupo (fluxo 2). Quando o processamento de uma requisio termina, o primrio realiza um ltimo checkpoint e envia uma resposta ao cliente (fluxo3).
1 3
CLIENTE
2 1
primrio
GRUPO DE RPLICAS
Figura 6.1: Replicao Passiva.
As falhas temporais do membro primrio so interpretadas como um crash, ou seja, se o primrio demorar para responder a um cliente, ou para realizar um checkpoint, o cliente e/ou os membros passivos do grupo vo deduzir, por decurso de tempo, que o primrio parou de funcionar. Se o primrio falha, os membros remanescentes elegem um novo primrio, que assume como o nico membro ativo do grupo. Durante a eleio, o grupo torna-se indisponvel.
6.2.2 Replicao Ativa

No modelo de replicao ativa, mostrado na Figura 6.2, todos os membros do grupo de rplicas recebem, executam e respondem cada requisio de cliente. As rplicas devem ser deterministas, ou seja, dado um mesmo estado inicial e um mesmo conjunto de mensagens, recebidas numa mesma ordem, todas as rplicas operacionais devem atingir um mesmo estado final. A Mquina de Estado foi descrita em Sch90 como um modelo de referncia para implementar servios tolerantes a faltas, usando replicao ativa, e coordenar as interaes entre clientes e grupos. Uma mquina de estado consiste de variveis de estado, que armazenam seu estado, e comandos, usados para transformar seu estado. Cada comando implementado por um programa determinista, cuja execuo pode modificar uma varivel de estado e produzir alguma sada. A mquina de estado garante o processamento de todas as requisies de um mesmo cliente, na ordem em que foram emitidas, e a ordenao total de requisies de clientes diferentes [Lam78].
94
CLIENTE
GRUPO DE RPLICAS
Figura 6.2: Replicao Ativa.
Esse modelo define as condies que devem ser satisfeitas, a fim de garantir a consistncia das rplicas: a) cada membro operacional do grupo deve receber toda requisio de cliente e b) todos os membros operacionais devem processar as requisies recebidas numa mesma ordem relativa.
6.2.3 Modelo de Replicao do SALIUS

A anlise das caractersticas de cada modelo levou escolha de um modelo baseado na replicao ativa, para o projeto do Servio de Replicao de Buffers do SALIUS. Na replicao passiva, o protocolo de replicao precisa garantir que o membro primrio propague seu estado para um nmero suficiente de membros passivos, antes de enviar uma resposta ao cliente, como uma condio indispensvel para oferecer um certo grau de tolerncia a faltas. Essa operao pode aumentar consideravelmente o tempo de resposta ao cliente, constituindo um fator impeditivo ao atendimento dos requisitos de desempenho do SALIUS. Na replicao ativa, a falha de uma rplica no interfere no comportamento das demais e o grupo continua disponvel, enquanto na replicao passiva, o servio fica interrompido, desde que um primrio falha, at que um novo primrio seja eleito. A escolha da replicao ativa, no caso especfico do SALIUS, no aumenta expressivamente a quantidade de recursos utilizados.
95
O processamento nas rplicas do Servidor de Replicao de Buffers mnimo: apenas o recebimento da mensagem e atualizao de estruturas de dados, na memria, portanto pode ser realizado em todas as rplicas. O nmero de rplicas necessrias, em geral, pequeno, porque a probabilidade de ocorrerem crashes simultneos, em diversas mquinas do sistema, tambm normalmente baixa. O protocolo de comunicao utilizado pelo Servio de Replicao de Buffers pode ser simplificado, mesmo adotando o modelo de replicao ativa. Por exemplo, o protocolo de comunicao no precisa garantir a entrega ordenada de mensagens: nas rplicas, as mensagens que chegam podem ser armazenadas de forma desordenada; a ordem importante apenas para o procedimento de recuperao, que precisa gravar os dados alterados na mesma ordem em que foram gerados. Como o sistema de arquivos do UNIX centralizado, as mensagens de replicao so geradas por processos executando numa mesma mquina; as mensagens podem incluir informaes que possibilitem uma ordenao posterior, quando um cliente iniciar um procedimento de recuperao.
6.3 Protocolo de Comunicao

O protocolo de comunicao define como ser a comunicao entre um cliente e o grupo de rplicas, e entre os membros do grupo. A comunicao ponto a ponto, tambm conhecida como unicasting, acontece quando um transmissor envia uma mensagem para um nico receptor [Tan95].
O Servio de Replicao de Buffers utiliza unicasting em algumas de suas interaes, como, por exemplo, quando uma rplica envia dados para o procedimento de recuperao do cliente. Porm, na maioria das interaes, o servio utiliza um tipo mais sofisticado de comunicao, denominada multiponto, envolvendo um transmissor e vrios receptores: um cliente do servio de replicao envia mensagens para todo o grupo de rplicas, pois o modelo adotado de replicao ativa; eventualmente, uma rplica pode precisar interagir com as demais rplicas do grupo, a fim de restabelecer a sua consistncia. Existem vrias maneiras de implementar a comunicao multiponto. O transmissor pode, por exemplo, fazer mltiplos unicasts, sendo um para cada receptor. Nesse caso, o transmissor deve conhecer todos os membros do grupo, para que possa enderear as mensagens enviadas. Para cada interao entre um processo transmissor e um grupo de n rplicas, circulam n mensagens, contribuindo para aumentar o trfego na rede.
96
Multicasting uma tcnica mais eficiente de implementar a comunicao multiponto [ANS90] [Lit92]. Um multicast uma mensagem enviada a um grupo e encaminhada, atravs da rede, para todos os membros do grupo. Em cada interao entre um processo transmissor e um grupo, trafega apenas uma mensagem na rede. Multicasting uma forma transparente de comunicao grupal, pois o transmissor no precisa saber quantos so os membros de um grupo, nem onde eles esto localizados [Tan95]. O esquema de multicasting pode ser implementado de vrias maneiras e em vrias camadas diferentes (enlace, rede, transporte). Em algumas redes, por exemplo, possvel criar um endereo de rede especial, para multicasting, como o endereo de Internet de classe D, atravs do qual vrias mquinas podem escutar. Assim, se o transmissor enviar uma mensagem para um endereo de multicasting, a mensagem ser entregue a todas as mquinas que estiverem escutando nesse endereo [Tan95]. possvel, ento, assinalar todos os membros de um grupo de rplicas a um mesmo endereo de multicasting. A escolha de um protocolo de comunicao deve considerar as garantias oferecidas, referentes entrega de mensagens, e o impacto dessas garantias no desempenho. Quanto menos garantias o protocolo de comunicao oferece, menor a carga de processamento introduzida no sistema, contribuindo para um melhor desempenho. Em contraposio, o protocolo de replicao precisa ser mais complexo, para a manuteno da consistncia das rplicas. Quanto mais garantias o protocolo de comunicao oferece, mais simples pode ser o protocolo de replicao. Porm, maior tambm a carga de processamento introduzida pelo protocolo de comunicao, diminuindo o desempenho do sistema.
O Servio de Replicao de Buffers adota o protocolo de comunicao UDP Multicast. Esse protocolo adiciona a facilidade de realizar multicasting ao protocolo UDP (User Datagram Protocol) [Bir96]. O UDP Multicast no garante a entrega confivel de mensagens a todos os membros do grupo, ou seja, uma mquina pode receber uma mensagem que outras perderam. Esse protocolo tambm no garante a entrega ordenada das mensagens. Alm disso, pode ocorrer duplicao de mensagens. Na maioria dos servios implementados atravs de replicao ativa, necessrio garantir a entrega atmica, ordenada e no duplicada de mensagens, para a manuteno da consistncia das rplicas. Por isso, a utilizao do protocolo UDP Multicast nesses sistemas introduziria uma grande complexidade ao protocolo de replicao, a fim de suprir os requisitos de comunicao no atendidos pelo protocolo de comunicao.
97
Entretanto, O UDP Multicast um protocolo adequado ao Servio de Replicao de Buffers do SALIUS, porque: apesar das limitaes citadas, o protocolo UDP Multicast tem a vantagem de ser simples e adicionar uma carga de processamento menor ao sistema, se comparado com os protocolos de multicasting confivel (que garantem a entrega atmica, ordenada e no duplicada de mensagens), possibilitando uma entrega mais rpida de mensagens; o Servio de Replicao de Buffers est projetado para ser utilizado numa estrutura de rede local, com uma probabilidade pequena de perder pacotes. Assim, o projeto assume uma abordagem otimista, considerando que as mensagens sero entregues, na maioria das vezes; as mensagens trafegadas pelo servio so pequenas (aproximadamente, o equivalente a um bloco do arquivo). Portanto, para a maioria dos sistemas de arquivos UNIX, com tamanho de bloco de 4Kb, cada mensagem no SALIUS pode equivaler a uma nica mensagem UDP, cujo tamanho mximo tipicamente de 8Kb[Bir96].
O Servio de Replicao de Buffers do SALIUS consegue contornar as limitaes do UDP Multicast, atravs de um protocolo de replicao simples, que ser descrito a seguir.
6.4 Protocolo de Replicao

Um protocolo de replicao define as possveis interaes entre um cliente e um grupo de rplicas e entre os membros do grupo. A especificao do protocolo de replicao do SALIUS assume que: o protocolo de comunicao possui uma semntica no-confivel (no garante a entrega atmica, ordenada e no duplicada de mensagens); em todas as mquinas do sistema, s ocorrem falhas por crash; o sistema assncrono, isto , no existe um tempo mximo para uma mensagem chegar ao seu destino, mas possvel estimar um de tempo de transmisso, dentro do qual a maior parte das mensagens entregue; quando uma rplica no responde a uma requisio, dentro de um intervalo de tempo mximo predefinido, o cliente interpreta que essa rplica falhou.
6.4.1 Informaes de Controle de um Pedido de Replicao

Cada pedido de replicao que um cliente envia ao grupo de rplicas contm dados e metadados alterados no sistema de arquivos e um cabealho com as seguintes informaes de controle adicionais:
6.4.1.1 Informaes Relacionadas com a Entrega das Mensagens

So informaes utilizadas em aes previstas no protocolo de replicao, com o objetivo de compensar as limitaes do protocolo de comunicao UDP Multicast. Por exemplo, as mensagens de replicao precisam conter um identificador de pedido, nico e global, para que uma rplica consiga reconhecer e descartar os pedidos duplicados. Alm disso, a identificao de um pedido deve indicar a ordem na qual ele foi gerado, para que uma rplica consiga detectar que deixou de receber algum pedido, iniciando um procedimento de regenerao, junto s demais rplicas, para recuperar as mensagens perdidas. Como o sistema de arquivos do UNIX centralizado, possvel implementar um contador de pedidos, nico para cada sistema de arquivos e armazenado numa regio crtica da memria. Assim, antes de enviar uma mensagem de replicao, um cliente obtm um nmero de pedido e monta o identificador do pedido formado da associao das seguintes informaes: um identificador da mquina onde o sistema de arquivos reside, o identificador do sistema de arquivos e o nmero do pedido.
6.4.1.2 Informaes para a Limpeza dos Logs de Replicao

As rplicas precisam descartar todos os dados replicados, que tenham sido gravados no sistema de arquivos original. Um pedido de replicao deve conter o nmero de pedidos anteriores, cujos dados tenham sido gravados em disco.
6.4.1.3 Informaes para o Procedimento de recuperao

O identificador de pedido tambm necessrio ao procedimento de recuperao: como o nmero do pedido obtido durante a execuo de uma operao de atualizao e nico para cada sistema de arquivos, esse nmero reflete a ordem na qual as atualizaes foram originalmente realizadas; ento, o procedimento de recuperao utiliza o identificador de pedido, para ordenar os dados recuperados, antes de grav-los no disco, simulando uma repetio das operaes de atualizao. Alm do identificador de pedido, a mensagem de replicao deve incluir outras informaes de controle, que indicam a posio, dentro do sistema de arquivos, onde os dados devem ser gravados. Um pedido de replicao pode conter diferentes tipos de dados, tais como: bloco de dados, superbloco e n-i. Um mesmo pedido pode conter mais de um item de dado. Para cada item de um pedido, preciso informar: o tipo e o tamanho da informao e sua posio no sistema de arquivos.
99
6.4.2 Operaes do Protocolo de Replicao

O protocolo de replicao permite que as seguintes operaes sejam realizadas: send_replica (p, flag_init, i_srb): utilizada por um cliente, para enviar um pedido de replicao para o grupo de rplicas. O parmetro p o identificador do pedido; o parmetro flag_init um flag indicando que o SRB precisa ser inicializado; o parmetro i_srb informa a encarnao atual do SRB; receive_request (p, flag_init, i_srb): utilizada por um membro do grupo de rplicas, para receber uma requisio de um cliente. Existem dois tipos diferentes de requisies: um pedido de replicao enviado por um SAC; ou um pedido de recuperao enviado por um processo de recuperao do SALIUS, ou por uma rplica em regenerao. O tipo de pedido indicado no cabealho da mensagem e orienta o servidor quanto ao processamento que deve ser executado; send_reply (p, i): utilizada por um membro do grupo de rplicas, para enviar uma mensagem ao cliente, confirmando a realizao de um pedido de replicao (p) e informando a encarnao atual da rplica (i); receive_reply (p, i): utilizada por um cliente, para receber uma resposta de um membro do grupo de rplicas, confirmando a realizao de um pedido de replicao e informando a encarnao da rplica em (i); init_recovery: utilizada por um cliente, ao retornar de um crash, para informar ao grupo de rplicas o incio do procedimento de recuperao. Tambm utilizada por uma rplica, aps um crash, ou ao perceber que se encontra desatualizada, para informar aos demais membros do grupo o incio de um procedimento de regenerao; send_status (p, i): utilizada por um membro do grupo de rplicas, para informar o ltimo pedido de replicao atendido (p) e a sua encarnao corrente (i); receive_status (p, i): utilizada por um cliente, ou uma rplica em regenerao, para receber o estado de atualizao de uma rplica, ou seja, a encarnao e o ltimo pedido de replicao atendido; request_data_recovery (p): utilizada por um cliente, ou por uma rplica em regenerao, para requisitar a outra rplica do grupo o envio de dados do log de replicao, referentes a pedidos maiores que um pedido informado (p); send_data_recovery (l): utilizada por um membro do grupo de rplicas, para enviar a um cliente, ou a uma rplica em regenerao, uma mensagem contendo os dados log de replicao (l) previamente solicitados; receive_data_recovery (l): utilizada por um cliente em recuperao, ou por uma rplica em regenerao, para receber uma mensagem contendo dados do log de replicao (l).
100
6.4.3 Algoritmo de Replicao

O algoritmo de replicao define o comportamento de um cliente e de um grupo de rplicas, para realizar a replicao durante o processamento das primitivas do SALIUS. Aps realizar as alteraes de dados e metadados de um sistema de arquivos, na memria principal, o cliente (SAC) tenta replicar todos os dados alterados, antes de retornar o controle para a aplicao. Para isso, o cliente envia um pedido de replicao ao grupo de rplicas do SRB (uma mensagem multicast para todas as rplicas). Alm de dados e metadados alterados, uma mensagem de replicao inclui um cabealho com informaes de controle. Para montar o cabealho da mensagem, o cliente adquire um nmero de pedido, gerado atravs de um contador de pedidos, armazenado numa regio crtica da memria. Esse nmero de pedido associado com um identificador do sistema de arquivos e um identificador da mquina onde o sistema de arquivos reside, para compor o identificador do pedido. O cabealho de uma mensagem de replicao tambm contm um flag (flag_init), cuja funo informar ao grupo de rplicas se o SRB precisa ser inicializado. A inicializao do SRB faz parte do tratamento de falhas, discutido no item 5.3.3. O cliente guarda o estado do SRB numa varivel de estado (srb_inicializado), para cada sistema de arquivos. Toda vez que um cliente vai replicar dados, ele consulta essa varivel: se o SRB no estiver inicializado, o cliente ativa o flag_init, para ordenar uma inicializao ao grupo de rplicas. Caso contrrio, o cliente envia o pedido de replicao com o flag_init desligado. A operao que monta um sistema de arquivos torna a varivel srb_inicializado falsa, forando uma inicializao, ao primeiro pedido de replicao de um sistema de arquivos. O cliente tambm inclui o nmero da encarnao corrente do SRB (i_srb) no cabealho do pedido. O esquema de encarnaes utilizado para que uma rplica do SRB possa verificar se deixou de receber algum pedido, no qual o cliente solicita uma inicializao ao grupo de rplicas. Se uma rplica parar de receber pedidos de clientes por um certo tempo, devido a falhas no servio de comunicao, ela pode deixar realizar uma inicializao. Quando a rplica volta a receber pedidos, ela verifica se a sua encarnao est atualizada. O esquema de encarnaes funciona da seguinte maneira: toda vez que uma rplica passa por um processo de inicializao, ela incrementa a sua encarnao; quando uma rplica envia uma mensagem de confirmao a um cliente, ela informa a sua encarnao atual; ao receber as mensagens de confirmao, um cliente guarda o maior nmero de encarnao recebido numa varivel de estado (i_srb); todo pedido de replicao contm o valor armazenado na varivel i_srb. Assim, quando uma rplica recebe um pedido de replicao, ela compara a sua encarnao com a encarnao corrente do SRB: se a encarnao da rplica for anterior encarnao do SRB, ela detecta que deixou de fazer alguma inicializao e entra num processo de regenerao, mantendo-se atualizada.
Quando termina de montar a mensagem, o cliente tenta realizar a replicao. Para isso, envia o pedido ao grupo de rplicas e espera pela confirmao da replicao, durante um intervalo de tempo predefinido. Se, nesse tempo, chegarem mensagens de confirmao de, pelo menos, r rplicas distintas do servidor, todas da encarnao mais recente, o cliente assume que a replicao foi bem-sucedida. Caso contrrio, o cliente retransmite o pedido e aguarda novamente por respostas. Isso acontece um nmero finito de vezes (max_retry, configurado pelo administrador do sistema), antes do cliente interpretar uma falha no servio de replicao. Se a replicao for bem-sucedida, o cliente ajusta a encarnao corrente do SRB, guardando na varivel i_srb o maior nmero de encarnao recebido nas mensagens de confirmao. Se o SRB no estava inicializado, o cliente tambm atualiza a varivel srb_inicializado, indicando que o SRB foi inicializado com sucesso. A seguir, o cliente retorna o controle para a aplicao, informando o sucesso da operao solicitada. Quando um cliente detecta uma falha no SRB, durante uma tentativa de replicar dados, suas aes dependem do estado do SRB, indicado pela varivel srb_inicializado: a) se o SRB estiver inicializado, significa que essa a primeira tentativa de replicar dados que falha, desde a ltima inicializao: o cliente torna falsa a varivel srb_inicializado e executa o comando sync, gravando no disco todas as atualizaes pendentes do sistema de arquivos, inclusive os dados da operao em curso; b) se o SRB no estiver inicializado, significa que o comando sync j foi executado anteriormente, no havendo atualizaes pendentes na memria: o cliente realiza a gravao sncrona apenas dos dados e metadados alterados pela operao em curso.
102
CLIENTE: altera dados em memria; adquire contador (p); incrementa contador (p); if (srb_inicializado) then flag_init = false; else flag_init = true;
/* adquire o contador de pedidos */ /* incrementa o contador de pedidos */ /* preenche flag de inicializao do SRB */
retry = 0; /* inicia o contador de tentativas */ do { retry = retry + 1; send_replica (p, flag_init, i_srb); start_timeout; /* inicia a contagem do tempo */ num_replies = 0; /* inicia o nmero de respostas da tentativa */ i_max = 0; do { receive_reply (p, i); if (i > i_max) then { i_max = i; num_replies = 1; /* reinicia a contagem de respostas */ } else incrementa num_replies; } while not (timeout) and (num_replies < r); } while (num_replies < r) and (retry < max_retry); if (num_replies r) then { libera contador (p); if not (srb_inicializado) then { srb_inicializado = true; i_srb = i_max; } } else { decrementa contador (p); libera contador (p); if (srb_inicializado) then { srb_inicializado = false; sync (); } else gravao sncrona; } return ok;
/* sucesso na replicao */
/* guarda a encarnao do SRB */ /* SRB falhou */
103
Ao receber um pedido de um cliente, o Servidor de Replicao de Buffers, primeiro, verifica se esse pedido j foi atendido, descartando as mensagens duplicadas. Se for um novo pedido, o servidor cria um processo filho para processar o pedido e volta a aguardar novas requisies, possibilitando o atendimento de pedidos de outros clientes. O processo filho, ento, realiza o processamento adequado ao tipo de pedido. Quando se trata de um pedido de replicao, o servidor verifica se o cliente solicitou o procedimento de inicializao, atravs do flag_init. Se o flag estiver ligado, o servidor realiza o procedimento de inicializao: descarta todos os dados do log de replicao, relacionados com o sistema de arquivos informado no pedido. Ao inicializar, o servidor tambm atualiza a sua encarnao para uma encarnao imediatamente seguinte encarnao atual do SRB, informada no pedido do cliente (i_srb). Durante uma inicializao do SRB, uma rplica pode receber vrios pedidos do cliente, solicitando a inicializao: o cliente s considera o SRB inicializado quando recebe a confirmao de r rplicas; enquanto essa condio no satisfeita, o cliente continua enviando pedidos com o flag_init ligado. Cada rplica do servidor s deve incrementar a sua encarnao uma nica vez, a cada inicializao do SRB. Por isso, o servidor mantm uma varivel de controle, em_inicializao. Se a varivel estiver falsa, significa que esse o primeiro pedido de inicializao recebido pela encarnao atual: nesse caso, o servidor atualiza o nmero da sua encarnao e torna a varivel em_inicializao verdadeira. Ao receber o primeiro pedido de replicao com o flag_init desligado, significa que a inicializao do SRB foi concluda com sucesso, ento o servidor torna a varivel em_inicializao novamente falsa. Quando um servidor recebe um pedido de replicao com o flag_init desligado, ele verifica o nmero do pedido e a encarnao atual do SRB: se o nmero do pedido for maior que o pedido esperado, significa que o servidor deixou de receber algum pedido; se o nmero da encarnao informada for maior que o da encarnao atual do servidor, significa que o servidor deixou de passar por algum processo de inicializao. Nos dois casos, a rplica encontra-se desatualizada. Portanto, o servidor executa um procedimento de regenerao, antes de voltar a atender aos pedidos de replicao. Ao reiniciar de um crash, uma rplica atribui zero a sua encarnao, para que ela passe, necessariamente, por um procedimento de regenerao. Finalmente, o servidor envia uma mensagem de confirmao ao cliente, informando a sua encarnao corrente, e armazena os dados recebidos num log de replicao, na memria principal.
104
SERVIDOR: for (; ;) { receive_request (p, flag_init, i_srb); verifica duplicidade; if novo_pedido then { cria processo filho; } }
PROCESSO FILHO: if replication then { /* atende ao pedido de replicao */
if (flag_init) then { /* inicializao */ reinicia log; /* descarta log */ if not (em_inicializao) then { / * primeiro pedido de inicializao */ i_replica = i_srb + 1; /* atualiza a encarnao da rplica*/ em_inicializao = true; } } else { /* cliente no detectou falha no SRB */ if ((i_srb > i_replica) or (p > pedido_esperado)) then { proc_regeneration; if (em_inicializao) then em_inicializao = false; } send_reply (p, i_replica); pedido_esperado = p + 1; armazena dados no log; } else if recovery then proc_serve_recovery; /* atende ao pedido de recuperao */
105
6.4.4 Algoritmo de Regenerao de uma Rplica

Quando uma rplica reinicia, depois de sofrer um crash, ou verifica que se encontra desatualizada, ela realiza um procedimento de regenerao, para tornar-se consistente, antes de voltar a atender s requisies de clientes. Para isso, executa um processo que envia uma mensagem ao grupo de rplicas, informando o incio da regenerao. Nas demais rplicas, o servidor executa o procedimento proc_serve_recovery (o mesmo procedimento utilizado para atender a um pedido de recuperao de um sistema de arquivos), para atender ao pedido de regenerao. Ao ser informado do incio de um procedimento de regenerao, o servidor envia uma resposta rplica em regenerao, informando o seu estado de atualizao, ou seja, a sua encarnao atual e o ltimo pedido de replicao atendido. preciso observar que, atravs do algoritmo de replicao, uma rplica no tem como perceber que deixou de receber a ltima atualizao de um sistema de arquivos e, ainda assim, considera-se atualizada. Por isso, importante que o processo de regenerao receba respostas de vrias rplicas, para que possa eleger uma rplica atualizada como a provedora dos dados necessrios regenerao. O processo de regenerao aguarda a chegada de respostas, durante um tempo mximo e predefinido. Se, nesse tempo, no chegarem as repostas de, pelo menos, u rplicas distintas, todas na encarnao mais recente, o processo de regenerao repete a tentativa, at obter sucesso. O nmero de rplicas que devem responder a um pedido de regenerao um valor conhecido e configurado pelo administrador do sistema, estando situado no intervalo n - f < u n (o conjunto de rplicas possivelmente ativas). A seguir, o processo de regenerao elege uma rplica atualizada (com a maior encarnao e o maior pedido). O processo envia uma mensagem rplica eleita, solicitando os dados do log de replicao referentes aos pedidos de replicao maiores que um pedido informado p. O valor de p depende da situao da rplica em regenerao:
a) se a encarnao da rplica em regenerao for anterior maior encarnao recebida (se ela estiver se recuperando de um crash, a sua encarnao estar com valor zero), o processo de regenerao atribui o valor zero a p, requisitando todo o log rplica eleita. Ao receber o log de replicao, o processo de regenerao armazena esse log em sua memria, descartando qualquer log antigo existente; b) se a rplica em regenerao estiver na mesma encarnao da rplica eleita, significa que ela apenas deixou de receber alguns pedidos, mas no precisa substituir seu log de replicao. Assim, o processo de regenerao informa em p o nmero do ltimo pedido de replicao existente no log local. Ao receber os dados da rplica eleita, o processo de regenerao completa o log com dados dos pedidos que faltavam.
PROCEDIMENTO DE REGENERAO: proc_regeneration { do { init_recovery; /* informa o incio da regenerao */ start_timeout; /* inicia a contagem do tempo */ num_replies = 0; /* inicia o nmero de respostas */ i_max = 0; do { receive_status (p, i); if (i > i_max) then { i_max = i; num_replies = 1; } else incrementa num_replies; } while not (timeout) and (num_replies < u); } while (num_replies < u); elege uma rplica; if (i_replica < i_max) then p = 0; else p = maior pedido do log; request_data_recovery (p); receive_data_recovery (l); armazena dados no log; }
SERVIDOR: proc_serve_recovery; { if init_recovery then send_status (p, i); else { ler dados do log (p); send_data_recovery (l); } }
107
6.4.5 Algoritmo de Recuperao

Quando um cliente reinicia, aps um crash, o procedimento de recuperao deve ser executado, para restaurar o sistema de arquivos. Para isso, o procedimento de recuperao interage com o grupo de rplicas, a fim de obter os dados replicados antes do crash. O algoritmo de recuperao muito semelhante ao algoritmo de regenerao.
CLIENTE: retry = 0; do { retry = retry + 1; init_recovery; /* informa o incio da recuperao */ start_timeout; /* inicia a contagem do tempo */ num_replies = 0; /* inicia o nmero de respostas */ i_max = 0; do { receive_status (p, i); if (i > i_max) then { i_max = i; num_replies = 1; } else incrementa num_replies; } while not (timeout) and (num_replies < u); } while (num_replies < u) and (retry < max_retry); if (num_replies u) then { elege uma rplica; request_data_recovery (0); receive_data_recovery (l); ordena pedidos do log; grava dados no disco; } else fail;
/* requisita todo o log */ /* recebe o log */
O cliente envia uma mensagem para o grupo de rplicas, informando o incio da recuperao. O servidor executa o procedimento proc_serve_recovery, para atender a um pedido de recuperao de um cliente (o mesmo procedimento que atende um pedido de uma rplica em regenerao). Cada rplica operacional envia uma resposta ao cliente,
108
informando o seu estado de atualizao, ou seja, a sua encarnao e o ltimo pedido de replicao atendido. O cliente espera, por um tempo mximo e predefinido, pela resposta de, pelo menos, u rplicas (n - f < u n), sendo u um parmetro informado ao procedimento de recuperao. Caso no cheguem as u respostas esperadas, o cliente retransmite o pedido e aguarda novamente por respostas. Isso acontece um nmero finito de vezes (max_retry). Quando o nmero de tentativas se esgota, caso o cliente no tenha recebido as respostas esperadas, o processo de recuperao falha. O administrador do sistema pode repetir o processo de recuperao, atribuindo um valor menor para u. O restante do procedimento de recuperao acontece da seguinte maneira: com base nas informaes recebidas, o cliente elege uma rplica atualizada e requisita mesma o log de replicao; a rplica eleita envia o log de replicao para o cliente; de posse do log, o cliente grava os dados de cada pedido de replicao no sistema de arquivos em disco, obedecendo ordem na qual os pedidos foram originalmente gerados.
6.5 Processamento nas Rplicas

O processamento executado pelo Servidor de Replicao de Buffers muito simples. Aps receber um pedido de replicao, o servidor armazena essa mensagem num log, mantido inicialmente na memria principal. Para agilizar o procedimento de recuperao, o servidor mantm um log para cada sistema de arquivos. Assim, no momento da recuperao, as mensagens de cada sistema de arquivos j estaro agrupadas.
6.5.1 Limpeza dos Logs de Replicao

medida que os pedidos de replicao vo sendo processados, os logs aumentam de tamanho. Para liberar espao na memria principal, o servidor realiza um procedimento de limpeza, descartando do log todos os dados j estabilizados no sistema de arquivos de origem, ou seja, os dados j gravados em disco. Para realizar a limpeza dos logs, o servidor precisa saber quais os dados que podem ser descartados. A cada pedido de replicao, o cliente informa ao servidor o nmero do maior pedido j estabilizado. O servidor, ento, descarta o pedido informado e todos os pedidos anteriores. O cliente mantm uma tabela de pedidos pendentes em sua memria, para controlar os pedidos que j foram estabilizados. Essa tabela mantm, para cada pedido, uma lista invertida, com os nmeros de todos os blocos de dados replicados pelo pedido. Quando um bloco gravado no disco, ele retirado das listas invertidas. Assim, quando a lista de blocos de um pedido torna-se vazia, significa que aquele pedido foi estabilizado. Ao enviar
um pedido de replicao, o cliente consulta a tabela de pedidos pendentes, para enviar ao grupo de rplicas o nmero do maior pedido j estabilizado. A informao adicional enviada em cada pedido de replicao pequena (apenas o nmero do maior pedido j estabilizado). Portanto, no influencia significativamente no tempo da replicao. Adicionalmente, essa soluo apresenta uma alta probabilidade de evitar a Situao Atpica da Recuperao, apresentada no item 5.6.3. Contudo, o processamento adicional no cliente pode atrapalhar o desempenho do sistema. Existe uma forma mais simples de realizar a limpeza dos logs: periodicamente, o servidor descarta do log todos os pedidos armazenados por um perodo superior a 2t, sendo t o tempo mximo que um bloco permanece na cache de arquivos do cliente, antes de ser gravado em disco. Caso essa ao no libere espao suficiente na memria, o procedimento de limpeza grava uma parte de cada log no disco, comeando pelos logs maiores, at reduzir o tamanho de todos os logs para um percentual predefinido pelo administrador do sistema. Essa soluo apresenta o inconveniente de vincular o comportamento do servidor ao comportamento do cliente: se um cliente aumentar o seu tempo t, o servidor precisar ajustar o tempo mximo que um pedido de replicao permanece no log. Na prtica, entretanto, existe um valor padro para t (de trinta segundos), adotado pela maioria dos sistemas de arquivos do UNIX. Assim, embora a primeira soluo seja mais genrica e elegante, essa soluo uma forma prtica de reduzir o custo da operao de limpeza dos logs.
6.6 Consideraes Finais

O projeto de um Servio de Replicao de Buffers apresentado visa atender, de forma equilibrada, aos requisitos de desempenho e confiabilidade. O balanceamento entre tais requisitos obtido atravs da escolha dos valores de n (nmero de rplicas do grupo) e r (nmero de rplicas que precisam confirmar um pedido de replicao). Quanto maior r, maior a probabilidade da informao poder ser recuperada, caso o sistema de arquivos sofra um crash; por outro lado, quanto menor r, mais rapidamente a confirmao ser recebida pelo cliente. O item 6.2.1 apresentou as razes para que o SALIUS seja implementado por k rplicas, com k f + 1, sendo f o nmero de faltas que o SALIUS deseja tolerar, e demonstrou que o SRB deve ser composto de n rplicas, sendo n f. O item 6.2.2 demonstrou a necessidade de, pelo menos, r rplicas responderem a um pedido (r = f), para que uma replicao seja considerada bem-sucedida. Portanto, se n = f, ento, basta que uma rplica falhe, para que o SRB deixe de atender aos pedidos de replicao e o SALIUS passe a utilizar a gravao sncrona, deixando de ser vantajoso, em relao s tcnicas de armazenamento estvel existentes. Assim, quanto maior n - f, maior a probabilidade de,
pelo menos, f rplicas no falharem no atendimento a um pedido de replicao, diminuindo a ocorrncia de gravaes sncronas. Sendo freal o nmero de rplicas que realmente falham (freal f), o SRB s atende a um pedido de replicao, quando n - freal f. Como o freal mximo igual a f (nmero mximo de faltas suportado pelo SALIUS), fazendo n 2f, a nica possibilidade de falha do SRB ser devida a uma falha na comunicao entre o cliente e as rplicas. Num cenrio prtico, pode-se adotar uma abordagem otimista, assumindo que falhas na comunicao so raras e que durante um intervalo de tempo pequeno (suficiente para que o sistema de arquivos do UNIX grave as informaes "estveis" no disco) a probabilidade de duas rplicas falharem desprezvel. Assim, pode-se estabelecer: n = 2 e r = f = 1. Obviamente, muitos outros cenrios so possveis, mas somente uma experimentao, com uma implementao do servio, poderia indicar qual o melhor cenrio para uma determinada plataforma.
111
Captulo 7
7 Concluses
7.1 Sumrio da Dissertao

Garantir a estabilidade de informaes armazenadas um objetivo dos sistemas de arquivos. Um armazenamento s pode ser considerado totalmente estvel, se no existir chance alguma do seu contedo ser destrudo. Na prtica, nenhum sistema de arquivos capaz de cumprir inteiramente tal condio, porque sempre haver a possibilidade de falhas de componentes do sistema provocarem a destruio de dados armazenados. Porm, quando o sistema sofre especificamente um crash, os dados mantidos na memria voltil so apagados, enquanto os dados gravados em disco so preservados. Assim, assumindo uma semntica de falha por crash, um sistema de arquivos pode garantir a estabilidade de informaes armazenadas, se puder grav-las em disco. A estabilidade de dados no o nico requisito importante para as aplicaes atuais. O surgimento de novos tipos de aplicaes, como os servios de comrcio eletrnico e os servios de banco a domiclio, exige que os servidores de arquivos sejam capazes de garantir um certo nvel de desempenho, alm de prover o armazenamento estvel. Os sistemas de arquivos tradicionais realizam a gravao sncrona em disco, como um meio de garantir a estabilidade de dados armazenados pelas aplicaes. No entanto, medida que a tecnologia evolui, a gravao sncrona vai deixando de ser uma tcnica de armazenamento estvel recomendvel, porque ela atrela o desempenho do sistema ao desempenho dos discos. Atualmente, os demais componentes de hardware, que integram um sistema de arquivos, so superiores aos discos em velocidade. As tendncias da tecnologia apontam para uma acentuao dessa diferena. Realizando gravaes sncronas, um sistema de arquivos no consegue aproveitar os avanos tecnolgicos para oferecer um melhor desempenho aos usurios, devido s limitaes impostas pela tecnologia de disco.
Captulo 6 Concluses 112
As tendncias da tecnologia e as necessidades das novas aplicaes motivam o desenvolvimento de novas tcnicas de armazenamento estvel, capazes de desvincular o desempenho dos sistemas de arquivos do desempenho dos discos. Esta dissertao apresentou a especificao de uma nova tcnica de armazenamento estvel, denominada SALIUS SERVIO DE ARMAZENAMENTO ESTVEL COM RECUPERAO PARA FRENTE BASEADO NA REPLICAO REMOTA DE BUFFERS , como uma alternativa s solues baseadas em gravao sncrona. A tcnica proposta baseia-se na replicao remota de buffers alterados na cache de arquivos. Assim, aps a ocorrncia de um crash, os dados apagados da memria principal podem ser recuperados, a partir de uma cpia mantida na memria principal de uma mquina remota, para que sejam, finalmente, gravados em disco, restabelecendo a consistncia do sistema de arquivos e mantendo as informaes estveis. O SALIUS constitudo de quatro componentes: uma interface, formada por um conjunto de primitivas, que so utilizadas pelas aplicaes, para solicitar que o SALIUS realize operaes sobre arquivos; um Servidor de Arquivos Complementar, que executa as operaes requisitadas ao SALIUS; um Servio de Replicao de Buffers, responsvel pela replicao confivel dos dados alterados na execuo de primitivas do SALIUS e pelo fornecimento de informaes necessrias recuperao do sistema de arquivos, aps um crash, e, finalmente, um Procedimento de Recuperao, cuja funo ler os dados alterados, a partir de uma rplica, e restaurar a consistncia do sistema de arquivos, garantindo a estabilidade de informaes gravadas atravs das primitivas do SALIUS. Uma aplicao pode escolher entre utilizar as primitivas do SALIUS, ou as primitivas do UNIX, de acordo com as suas necessidades. Quando o Servidor de Arquivos Complementar executa uma primitiva do SALIUS, solicita ao Servidor de Replicao de Buffers a replicao de todos os dados e metadados alterados. O SRB recebe os pedidos de replicao e mantm os dados replicados em um log de replicao. O procedimento de recuperao do SALIUS garante a recuperao de todos os dados armazenados atravs das primitivas do servio. Ele solicita ao Servidor de Replicao de Buffers o fornecimento de todos os dados replicados antes do crash. De posse desses dados, o procedimento de recuperao providencia grav-los em disco, refletindo no sistema de arquivos o efeito de todas as operaes que tenham sido realizadas com o uso do servio, antes do crash. As informaes so gravadas em disco, exatamente na mesma ordem na qual aconteceram originalmente, simulando uma repetio das atualizaes. O procedimento de recuperao do UNIX continua sendo necessrio, porque a alterao de dados e metadados, atravs da utilizao de primitivas originais do UNIX, pode levar o sistema de arquivos a um estado inconsistente.
Captulo 6 Concluses
113
Este trabalho evidenciou que a probabilidade do SALIUS conseguir alcanar os objetivos estabelecidos, de prover armazenamento estvel e de oferecer um desempenho superior s solues baseadas na gravao sncrona, depende da tecnologia utilizada e da forma como o Servio de Replicao de Buffers implementado. Foi apresentado um projeto de implementao para o Servio de Replicao de Buffers do SALIUS, atravs de um grupo de rplicas de um processo Servidor de Replicao de Buffers, executando em mquinas remotas. O projeto sugerido para o Servio de Replicao de Buffers adota o modelo de replicao ativa e utiliza o protocolo de comunicao UDP Multicast. O projeto tambm especifica um protocolo de replicao para o servio, detalhando as operaes possveis e os algoritmos utilizados na replicao de dados, na recuperao de um sistema de arquivos e na regenerao de uma rplica. O trabalho, tambm, demonstrou que o Servio de Replicao de Buffers pode balancear o atendimento aos requisitos de desempenho e confiabilidade, bastando ajustar o nmero de rplicas do grupo e o nmero de rplicas que precisam enviar uma mensagem de confirmao, para que a replicao seja considerada bem-sucedida.
7.2 Anlise do Trabalho

A especificao do SALIUS, proposta nesta dissertao, consegue atender aos requisitos previstos e detm potencialidades, para que uma implementao eficiente possa atingir os principais objetivos: o SALIUS adota realmente uma semntica de falha por crash, pois prev a replicao dos dados alterados na memria principal, durante as operaes que atualizam o sistema de arquivos, prevenindo a perda dessas dados na ocasio de um crash; o SALIUS transparente quanto localizao e quanto replicao, pois as aes para realizar a replicao de dados e manter a consistncia das rplicas so abstradas da aplicao. O SALIUS tambm consegue mascarar falhas no grupo de rplicas, porque continua realizando as operaes solicitadas, at mesmo quando todas as rplicas falham simultaneamente e o Servio de Replicao de Buffers interrompido; a administrao do SALIUS muito simples, cabendo ao administrador apenas definir o grupo de rplicas e reconfigur-lo; quando necessrio, executar o procedimento de recuperao e definir alguns parmetros, tais como: o nmero de faltas que precisam ser toleradas; o nmero de rplicas necessrias recuperao do sistema; o nmero de tentativas de replicao realizadas pelo SAC, antes de assumir que o SRB falhou; o tempo mximo que um cliente deve esperar por respostas do grupo de rplicas; o tempo mximo que um pedido de replicao permanece no log, antes de ser descartado;
Captulo 6 Concluses
114
o SALIUS mantm a semntica de compartilhamento do UNIX, porque preserva a ordem das operaes de escrita, quando um arquivo est sendo compartilhado. Para isso, o SALIUS utiliza um contador nico de pedidos de replicao, para cada sistema de arquivos. Quando um processo est atualizando o sistema de arquivos, adquire um nmero de pedido, o qual enviado no cabealho da mensagem de replicao. O procedimento de recuperao utiliza esse nmero de pedido para ordenar a gravao dos dados do log de replicao no disco; a especificao do SALIUS no requer a utilizao de hardware especial para a sua implementao. Assim, o objetivo de no acrescentar custos ao sistema consegue ser atendido; o procedimento de recuperao do SALIUS torna possvel a recuperao do sistema de arquivos aps um crash, garantindo a estabilidade das informaes armazenadas com o uso do servio; o SALIUS vincula o desempenho das operaes de escrita ao desempenho da rede, da memria e dos processadores utilizados na implementao, diminuindo a influncia da tecnologia de disco. Como as tendncias da tecnologia apontam para um grande aumento no potencial de processamento, na velocidade de acesso memria e nas taxas de transmisso de dados atravs de redes, o desempenho oferecido pelo SALIUS tambm tende a crescer; a confiabilidade do SALIUS tambm tende a aumentar com os avanos tecnolgicos, medida em que forem surgindo memrias e redes mais confiveis, pois diminui o risco de dados serem perdidos ou corrompidos enquanto estiverem armazenados na memria, ou enquanto estiverem trafegando pela rede; finalmente, uma implementao eficiente do Servio de Replicao de Buffers fundamental para que os objetivos de desempenho e confiabilidade do SALIUS sejam alcanados.
A Tabela 7.1 uma extenso da Tabela 4.1, apresentada no Captulo 4, e relaciona as caractersticas de vrios sistemas de arquivos robustos e do SALIUS, num quadro comparativo. Cada caracterstica apresentada refere-se a um dos objetivos do SALIUS, descritos no Captulo 5. As informaes associadas ao SALIUS consideram a probabilidade de uma implementao eficiente poder atender a cada um desses objetivos. Assim, o SALIUS tem um grande potencial para constituir um servio de armazenamento estvel de propsito geral, capaz de oferecer um melhor desempenho que os sistemas convencionais (baseados na gravao sncrona em disco), dotado de um mecanismo de recuperao para frente, que garante a estabilidade de dados de cache replicados, e a um custo acessvel, porque no depende de um hardware especial.
Captulo 6 Concluses
115
SISTEMAS BASEADOS EM LOG CACHE DE NVRAM RIO FILE CAHE SISTEMA ENVY SALIUS
ARMAZENAMENTO
ESTVEL
MELHORIA NO
DESEMPENHO
HARDWARE
ESPECIAL
MECANISMO DE
RECUPERAO
PROPSITO
GERAL
NO SIM SIM SIM SIM
SIM SIM SIM SIM SIM
NO SIM SIM SIM NO
SIM NO SIM NO SIM
SIM SIM SIM NO SIM
Tabela 7.1: Quadro comparativo do SALIUS com trabalhos relacionados.
O SALIUS apresenta a desvantagem de aumentar o consumo da banda passante do meio de comunicao, pois o funcionamento do servio exige a troca constante de mensagens entre os clientes e o SRB. Teoricamente, a utilizao de redes de alta velocidade diminuiria a probabilidade de um congestionamento inviabilizar a replicao de dados. Porm, somente a experimentao, atravs de uma implementao do servio, permitir uma avaliao mais precisa dos efeitos do aumento do trfego de dados na rede, causados pelo SALIUS.
7.3 Trabalhos Futuros

As idias discutidas nesta dissertao abrem caminho para pesquisas futuras. O principal trabalho a ser desenvolvido a implementao do SALIUS. Embora a especificao apresentada indique uma alta probabilidade de sucesso, a tcnica proposta s estar validada depois de implementada e utilizada como um sistema de armazenamento, num ambiente real de produo. O servio proposto pode ser estendido para o ambiente de sistema de arquivos em rede, como o NFS, ou para um sistema de arquivos distribudo. Para isso, preciso prever solues para o acesso concorrente a arquivos e para a manuteno da consistncia das rplicas, num ambiente distribudo. O SALIUS pode, tambm, ser adaptado para o ambiente do Windows NT. A dificuldade de criar uma especificao, uma implementao e um projeto para cada ambiente especfico pode ser solucionada com a utilizao de um framework.
116
Captulo 6 Concluses
Outro trabalho a ser desenvolvido o estudo do nmero ideal de rplicas do Servidor de Replicao de Buffers (n) e o nmero de rplicas que devem responder aos pedidos de replicao de um cliente (r), de modo a otimizar o atendimento aos requisitos de desempenho e confiabilidade. Este estudo pode ser realizado atravs de experincias com uma implementao do SALIUS, para diferentes valores de n e r. Um trabalho possvel a flexibilizao do tempo de permanncia dos dados na cache de arquivos, para os dados armazenados com o uso do SALIUS, conforme a disponibilidade de memria principal. Assim, havendo memria suficiente, esses dados poderiam ser mantidos na memria por um tempo maior. Quando o espao em memria se tornasse escasso, o tempo de permanncia dos dados na cache tambm diminuiria, dinamicamente. O efeito dessa estratgia para a otimizao do desempenho do sistema deve ser testado na prtica. A associao do SALIUS com outras tcnicas pode vir a otimizar o servio de armazenamento estvel oferecido: o uso de novas tecnologias de armazenamento secundrio, como a tecnologia RAID, pode contribuir para uma melhoria no desempenho do servio, enquanto a confiabilidade pode ser aprimorada, atravs de um mecanismo de proteo de memria, capaz de evitar que a memria seja sobregravada acidentalmente pelo sistema.
Captulo 6 Concluses
117
8 Bibliografia
[ABC+97] G. Alverson, P. Briggs, S. Coatney, S. Kahan and R. Korry. Tera Hardware-Software Cooperation. In Proceedings of the ACM/IEEE SC97, pp. 15-21, November 1997. T. Anderson, D. Culler and D. Patterson. A Case for NOW (Networks of Workstations). IEEE Micro 15(1): 54-56, February 1995. Also http:\\www.now.cs.berkeley.edu. G. Abandah, E. Davidson. Effects of Architectural and Technological Advances on the HP/Convex Exemplars Memory and Communication Performance. In Proceedings of the 25th Annual International Symposium on Computer Architecture, pp. 318-329, June 1998. T. Anderson, M. Dahlin, J. Neefe, D. Patterson, D. Roselli and R. Wang. Serverless Network File Systems. In Proceedings of the 15th Symp. on Operating Systems Principles, 109-126, December 1995. Also ACM Trans. On Computing Systems, 14(1): 41-79, February 1996. G. Amdahl. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities. In Proceedings of the AFIPS Spring Joint Computer Conference, April, 1967. Advanced Micro Devices, Inc. Technology Background AMDDL160 and DL320 Series Flash: New Densities, New Features. Publication 22271, May 1999. Advanced Micro Devices, Inc. Technology Background 3.0 Volt-only Page Mode Flash Memory Technology. Publication 22249, May 1999.
[ACP95]
[AD98]
[ADN+95]
[Amd67]
[AMD99]
[AMD99a]
Bibliografia
118
[ANS90]
ANSA. A Model for Interface Groups. ANSA, ISA Project, APM/RC 093.00, May 1990. ANSA. An Abstract Model for Groups. ANSA, ISA Project, APM/RC 259.01, June 1991. AT&T. UNIX System V, Release 3.2. System Administrators Guide. Prencice Hall, Inc. 1989. M. Bach. The Design of the UNIX Operating System. Prentice Hall T R, 1990. P
[ANS91]
[AT89]
[Bac86]
[BAD+92]
M. Baker, S. Asami, E. Deprit, J. Ousterhout and Margo Seltzer. NonVolatile Memory for Fast Reliable File Systems. In Fifth International Conference on Architectural Support for Programming Languages and Operating Systema (ASPLOS-V), pp. 10-22, October 1992. M. Beck, H. Bhme, M. Dziadzka, U. Kunitz, R. Magnus and D. Verworner. LINUX Kernel Internals. Second edition. Addison-Wesley, 1997. BGI Datentechnik GmbH. Solid State Disk Frequently Asked Questions. In www.silicondisk.com/SSD_tech_faq.html, October 1997. M. Baker, J. Hartman, M. Kupfer, K. Shirriff and J. Ousterhout. Measurements of a Distributed File System. In Proceedings of the 13th Symp. on Operating Systems Principles, pp. 198-212, October 1991. K. P. Birman. Building Secure and Reliable Network Applications. Manning Publications Co., 1996. M. Benatre, G. Muller, B. Rochat and P. Sanchez. Design decisions for the FTM: a general purpose fault tolerant machine. In Proceedings of the 1991 International Symposium on Fault-Tolerant Computing, pp. 71-78, June 1991. C. Cassidy. Understanding the Performance of Quantum Solid State Disks. In www.quantum.com/src/whitepapers/wp_ssdperformance.htm, Quantum Corporations whitepaper, 1998.
[BBD+97]
[BGI97]
[BHK+91]
[Bir96]
[BMR+91]
[Cas98]
Bibliografia
119
[CLG+94]
P. M. Chen, E. Lee, G. Gibson, R. Katz and D. Petterson. RAID: HighPerformance, Reliable Secondary Storage. ACM Computing Surveys, 26(2): 145-188, June 1994. P. M. Chen, Wee Teck Ng, G. Rajamani, C. M. Aycock. The Rio File Cache: Surviving Operating Systems Crashes. Seventh International Conference on Architectural Support for Programming Languages and Operating Systems, SIGPLAN Notices, 31(9): 74-83, September 1996. F. Cristian. Understanding Fault-Tolerant Distributed Systems. ACM Communications, 34(2): 56-78, February 1991. D. Comer and D. Stevens. Internetworking with TCP/IP,Principles, Protocols and Architecture. Vol. I. Prentice Hall International, Inc., 1991. D. Comer and D. Stevens. Internetworking with TCP/IP, Client/Server Programming and Applications BSD Socket Version. Vol. III. Prentice Hall International, Inc., 1993. H. Custer. Inside the Windows NT File System. Microsoft Press, 1994. M. Dahlin et al. A Quantitative Analysis of Cache Policies for Scalable Network File Systems. In Proceedings of the SIGMETRICS Conference on Measurement and Modeling of Computer Systems, pp. 150-160, May 1994. DEC 3000 300/400/500/600/700/800/900 AXP Models System Programmers Manual. Technical Report, Digital Equipament Corporation, July 1994. T. von Eicken, D. Culler, S. Goldstein and K. Schauser. Active Messages: A Mechanism for Integrated Communication and Computation. In Proceedings of the 19th ISCA, pp. 256-266, May 1992. J. Hartman, and J. Ousterhout. The Zebra Stripped Network File System. ACM Trans. On Computer Systems, 13(3): 274-310, August 1995. IEEE (Institute of Electrical and Eletronics Engineers) Standards. IEEE 802.3-1998 Edition. June 1998. Intel Corporation. Flash Memory, 1994.
120
[CNR+96]
[Cri91]
[CS91]
[CS93]
[Cus94] [Dah+94]
[DEC94]
[ECG+92]
[HO95]
[IEE98]
[Int94]
Bibliografia
[Int97]
Intel Corporation. Intel Architecture Software Developers Manual, Vol.1: Basic Architecture, Order Number 243190, 1997. P. Jalote. Fault Tolerance in Distributed Systems. Prentice Hall, 1994. L. Lamport. Time, Clocks, and the Ordering of Events in a Distributed System. ACM Communications, 21(7): 558-565, July 1978. L. Liang, S. T. Chanson, and G. W. Neufeld. Process Groups and Groups Communications: Classifications ans Requirements. IEEE Computer, February 1990. R. LaRowe, C. Ellis and L Kaplan. The Robustness os NUMA Memory Management. In Proceedings os Thirteenth Symposium on Operating Systems Principles, ACM, pp. 137-151, 1991. M. C. Little. Object Replication in a Distributed System. Ph.D. Thesis, University of Newcastle upon Tyne, Computing Laboratory, Technical Report Series, N 376, February 1992. E. Levy, and A. Silberschatz. Distributed File System: Concepts and Examples. Computing Surveys, 22(1): 321-374, December 1990. M. McKusick. Secondary Storage and Filesystems. ACM Computing Surveyes, 28(1), March 1996. P. Messina, D. Culler, W. Pfeiffer, W. Martin, J. Oden and G. Smith. Architecture. Communications of the ACM, 41(11): 36-44, November 1998. J.Menon and M. Hartung. The IBM 3990 Disk Cache. In Proceedings of the COMPCON, pp. 146-151, June 1988. M. McKusick, W. Joy, S. Leffler and S. Fabry. A Fast File System for UNIX. ACM Transactions on Computer Systems, 2(3): 181-197, August 1984. D. Major, G. Minshall and K. Powell. An Overview of the NetWare Operating System. In Proceedings of the 1994 Winter USENIX, pp. 355372, January 1994.
[Jal94] [Lam78]
[LCN90]
[LEK91]
[Lit92]
[LS90]
[McK96]
[MCP+98]
[MH88]
[MJL+84]
[MMP94]
Bibliografia
121
[MSC+90]
J. Moran, R. Sandberg, D. Coleman, J. Kepecs and B. Lyon. Breaking Through the NFS Performance Barrier. In Proceedings of the EUUG Spring, pp. 199-206, April 1990. T. Mudge et al. Strategic Directions in Computer Architecture. ACM Computing Surveyes, 28(4): 671-678, December 1996. P. Norton. Peter Nortons Inside the PC. Sams Publishing, 1995. M. Nelson, B. Welch, and J. K. Ousterhout. Caching in the Sprite Network File System. ACM Trans. on Computer Systems, 6(1): 134-154, February 1988. J. K. Ousterhout, A. Cherenson, F. Douglis, M. Nelson and B. Welch. The Sprite Network Operating System. IEEE Computer, 21(2): 23-36, February 1988. J. K. Ousterhout, Herve Da Costa, D. Harrison, J. Kunze, M. Kupfer and J. Thompson. A Trace-Driven Analysis of the UNIX 4.2 BSD File System. In Proceedings of the 1985 Symposium on Operating System Principles, pp. 15-24, December 1985. J. K. Ousterhout, and F. Douglis. Beating the I/O Bottleneck: A Case for Log-Structured File Systems. Technical Report, UCB/CSD 88/467, Computer Science Division, UC Berkeley, October 1988. Object Management Group. CORBA Services: Common Object Services Specification. Reference OMG 1995, http://www@omg.org. M. H. Olsen, E. Oskiewicz, and J.P. Warne. A Model for Interface Groups. Proceedings of SRDS-10. October 1991. S. Pakin, M. Lauria and A. Chein. High Performance Messagins on Workstations: Illinois Fast Messages (FM) for Myrinet. In Proceedings of Supercomputing 95, 1995. M. Rosenblum, and J. K. Ousterhout. The Design and Implementation of a Log-Structured File System. ACM Transactions on Computing Systems, 10(1): 26-52, February 1992. D. Ritchie and K. Thompson. The UNIX Time-Sharing System. The Bell System Thecnical Journal, 57(6): 1905-1930, July 1978.
122
[Mud+96]
[Nor95] [NWO88]
[OCD+88]
[OCH+85]
[OD88]
[OMG95]
[OOW91]
[PLC95]
[RO92]
[RT78]
Bibliografia
[Sat93] [SBM+93]
M. Satyanarayanan. Distributed System. ACM Press, 1993. M. Seltzer K. Bostic, M. McKusick and C. Staelin. An Implementation of a Log-Structured File System for UNIX. In Proceedings of the Winter 1993 USENIX Conference, pp. 307-326, January 1993. F. B. Schneider. Implementing Fault-Tolerant Services Using State Machine Approach: A Tutorial. ACM Computing Surveys, 22(4): 299319, December 1990. M. Seltzer, P. Chen and J. Ousterhout. Disk Scheduling Revisted. In Proceedings of the Winter 1990 USENIX Techinical Conference. January 1990. R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh and B. Lyon. Design and Implementation of the Sun Network File System. In Proceedings. of the Summer 1985 USENIX, pp. 119-130, June 1985. C. Stunkel, D. Shea, B. Abali, M. Atkins, C. Bender, D. Grice, P. Hochschild, D. Joseph, B. Nathanson, R. Swetz, R. Stucke, M. Tsao and P. Varker. The SP2 High-Performance Switch. IBM System J, 34(2): 185-204, 1995. T. Stabell-Kulo. Security and Log Structured File Systems. Operating Systems Review, 31(2): 9-10, April 1997. H. Stern. Managing NFS and NIS. OReilly & Associates, Inc, 1991, ISBN 0-937175-75-7. W. Stevens. Advanced Programming in the UNIX Environment. Addison Wesley, 1992. S.Sumimoto, H. Tezuka, A. Hori, H. Harada, T. Takahashi and Y. Ishikawa. The Design and Evalution of High Performance Communication using a Gigabit Ethernet. In Proceedings of the International Conference on Supercomputing, pp. 260-267, 1999. Tanenbaum, A. S. Modern Operating Systems. Prentice Hall, Inc, 1992. Tanenbaum, A. S. Distributed Operating Systems. Prentice Hall, Inc, 1995.
[Sch90]
[SCO90]
[SGK+85]
[SSA+95]
[Sta97]
[Ste91]
[Ste92]
[STH+99]
[Tan92] [Tan95]
Bibliografia
123
[TE95]
TIA (Telecommunications Industries Association) / EIA (Eletronics Industries Alliance) Standards. TIA/EIA-568-A. Commercial Building Telecommunications Cable Standard. Comittee TR-41.8.1, October 1995. Michael Wu and Willy Zwaenepoel. eNVy: Non-Volatile, Main Memory Storage Syatem. In Proceedings of the 1994 International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), October 1994.
[WZ94]
Bibliografia
124
Apndice A
9 Dados Replicados pelas Primitivas do SALIUS
Cada primitiva do SALIUS est associada a um conjunto de dados, os quais ela possivelmente altera e replica. Esse apndice analisa, para cada primitiva do servio, os dados que podem ser alterados e em que situaes tais alteraes acontecem.
a) s_creat
A primitiva s_creat utilizada para criar um arquivo. Ela aloca um n-i para o novo arquivo. Para isso, retira um n-i da lista de ns-i livres. Conseqentemente, a primitiva altera o superbloco, onde a lista de ns-i livres est armazenada e onde existe um contador de ns-i livres, que decrementado quando o n-i alocado. A primitiva tambm cria uma entrada para o n-i do arquivo no diretrio pai, alterando um bloco de dados desse diretrio. Se o tamanho do diretrio pai aumentar, a primitiva ajusta o tamanho de arquivo, armazenado no n-i desse diretrio. Se o ltimo bloco de dados do diretrio pai estiver cheio, a primitiva s_creat deve alocar um novo bloco para armazenar a entrada do arquivo, retirando um bloco da lista de blocos livres e alterando o contador de blocos livres, no superbloco. A primitiva s_creat precisa replicar todas as estruturas alteradas durante a sua execuo, o que pode consistir de: o superbloco, o n-i do novo arquivo, o n-i do diretrio pai e o bloco de dados do diretrio pai, com a entrada do novo arquivo.
Apndice A: Dados Replicados pelas Primitivas do SALIUS
125
b) open
A primitiva open abre um arquivo existente e pode criar um novo arquivo, caso o flag O_CREAT seja informado. No caso da criao de um arquivo, os dados que devem ser replicados so os mesmos da primitiva s_creat. Quando um arquivo existente aberto, normalmente, nenhum dado alterado, com exceo da situao em que o flag O_TRUNC informado. Nesse caso, todos os blocos do arquivo so liberados e a primitiva altera o n-i do arquivo, ajustando o tamanho do arquivo para zero. A operao de truncamento do arquivo tambm afeta o superbloco, pois os blocos liberados so inseridos na lista de blocos livres e o tamanho dessa lista incrementado. Assim, a primitiva open, quando invocada com a opo O_TRUNC, deve replicar o n-i do arquivo e o superbloco.
c) write
A primitiva write utilizada para escrever dados em um arquivo. Quando uma aplicao invoca essa primitiva, ela passa, como parmetro de entrada, um buffer de usurio contendo os dados a serem alterados. A primitiva deve replicar os dados informados, bem como a posio no arquivo, onde deve iniciar a gravao desses dados. Essa posio lida na tabela de arquivos abertos. Se o arquivo tiver sido previamente aberto com a opo O_APPEND, significa que os dados sero acrescidos ao final do arquivo, aumentando o seu tamanho. Nesse caso, a primitiva ajusta o tamanho do arquivo, no seu respectivo n-i. Quando o tamanho de um arquivo aumenta, novos blocos precisam ser alocados, alterando a lista de blocos livres e o superbloco. Desse modo, a primitiva write pode precisar replicar tambm o superbloco e o n-i do arquivo.
d) s_mkdir
A primitiva s_mkdir cria um novo diretrio. Assim, deve replicar os mesmos dados que a primitiva s_creat, com uma pequena diferena: ao invs do n-i de um arquivo, a primitiva vai replicar o n-i do novo diretrio. Adicionalmente a primitiva s_mkdir deve replicar o primeiro bloco de dados do diretrio, contendo as entradas . (do prprio diretrio) e .. (do diretrio pai).
Apndice A: Dados Replicados pelas Primitivas do SALIUS
126
e) s_mknod
A primitiva s_mknod utilizada para criar qualquer tipo de arquivo. Assim, deve replicar os mesmos dados que a primitiva s_mkdir, no caso da criao de um diretrio, ou os mesmos dados replicados pela primitiva s_creat, nos demais tipos de arquivos.
f) s_link
A primitiva s_link utilizada para criar uma nova entrada para um arquivo existente, num diretrio informado. Para isso, altera um bloco de dados desse diretrio, acrescentando a entrada para o arquivo. O diretrio aumenta de tamanho e a primitiva incrementa o tamanho do diretrio, armazenado no seu respectivo n-i. Se o ltimo bloco de dados do diretrio no comportar a nova entrada, a primitiva s_link precisa alocar um novo bloco de dados, alterando, portanto, a lista de blocos livres e o superbloco. Finalmente, a primitiva altera o n-i do arquivo, incrementando o contador de ligaes. Assim, a primitiva s_link sempre precisa replicar o n-i do arquivo, o n-i do diretrio o e o bloco de dados do diretrio contendo a nova entrada. Eventualmente, a primitiva pode necessitar alterar e replicar o superbloco.
g) s_unlink
A primitiva s_unlink utilizada para remover uma entrada de diretrio. Portanto, o bloco de dados do diretrio, onde a entrada est armazenada, alterado. Alm disso, a primitiva ajusta o tamanho do diretrio, que diminui, no seu respectivo n-i. Finalmente, a primitiva altera o n-i do arquivo, decrementando o nmero de ligaes existentes. Assim, a primitiva precisa replicar o bloco de dados de onde a entrada foi excluda, o n-i do diretrio e o n-i do arquivo. Quando a ltima entrada de diretrio de um arquivo removida, o arquivo excludo do sistema. Para isso, a primitiva s_unlink libera todos os blocos de dados do arquivo e o n-i associado. O superbloco tambm alterado, porque os blocos de dados liberados so inseridos na lista de blocos livres, enquanto o n-i do arquivo inserido na lista de ns-i livres. Nesse caso, a primitiva replica o superbloco e no replica o n-i do arquivo excludo, obviamente.
h) s_chown e s_chmod
As primitivas s_chown e s_chmode s alteram o n-i de um arquivo, ou de um diretrio, mudando, respectivamente, os atributos proprietrio e permisses de acesso. Assim, tais primitivas s precisam replicar o n-i do arquivo, ou do diretrio que est sendo alterado.
Apndice A: Dados Replicados pelas Primitivas do SALIUS 127

Dissertacao TatianaSimasStanchi

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Dissertacao TatianaSimasStanchi

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDADE FEDERAL DA PARABA

Centro de Cincias e Tecnologia Coordenao de Ps-Graduao em Informtica

Tatiana Simas Stanchi

Campina Grande / Paraba 2000

UNIVERSIDADE FEDERAL DA PARABA

Tatiana Simas Stanchi

rea de Concentrao: Sistemas Distribudos Orientador: Francisco Vilar Brasileiro

Campina Grande / Paraba 2000

2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.2.5 2.2.2.6

2.2.3 Armazenamento Estvel no Unix............................................................19 2.2.4 Procedimento de Recuperao do Unix ..................................................20

2.3 Tcnicas de Otimizao do Desempenho..............................................21

2.3.2 Tcnicas de Otimizao de Disco............................................................23

2.4 Sistema de Arquivos em Rede...............................................................25

3.1.3 Tecnologia de Memria...........................................................................36 3.1.4 Tecnologia de Rede.................................................................................37

3.2 Demanda de Armazenamento das Aplicaes.......................................38 3.3 Tendncias da Tecnologia......................................................................40

4.2 Cache de Memria No-Voltil.............................................................50

4.3 Rio File Cache........................................................................................53

4.4 Sistema de Armazenamento em Memria No-Voltil.........................56

5.3 Funcionamento Geral do SALIUS.........................................................63

5.4 Interface do SALIUS.............................................................................67

5.5 Servidor de Arquivos Complementar....................................................73

5.6 Procedimento de Recuperao ..............................................................77

5.7 Consideraes sobre Desempenho e Confiabilidade.............................86

6.2 Modelo de Replicao............................................................................93

6.3 Protocolo de Comunicao....................................................................96 6.4 Protocolo de Replicao........................................................................98

6.4.1.3 Informaes para o Procedimento de recuperao......................................99

6.5 Processamento nas Rplicas................................................................109

1.2 Armazenamento Estvel

1.4 Enfoque da Pesquisa

1.5 Estudo de Viabilidade

Tamanho do buffer (KB) 0,5 1 4 6 8 12 14 16 24

Tabela 1.1: Resultados dos testes de viabilidade.

1.6 Cenrio de Aplicao

1.7 Contribuies da Dissertao

1.8 Organizao da Dissertao

Captulo 2 Sistema de Arquivos Tradicional

2.1 Evoluo dos Sistemas de Arquivos

2.2 Sistema de Arquivos do UNIX

Captulo 2 Sistema de Arquivos Tradicional

2.2.1 Manipulao de Arquivos

Processos de usurio Nvel do usurio

Figura 2.2: Diagrama da manipulao de arquivos no UNIX.

Captulo 2 Sistema de Arquivos Tradicional

2.2.2.1 Organizao do Disco

Captulo 2 Sistema de Arquivos Tradicional

Bloco de boot Superbloco Ns-i Blocos de dados

Figura 2.2: Organizao de um sistema de arquivos do UNIX, no disco.

2.2.2.2 Endereamento de Blocos

Direto 9 Direto9 Indireto Simples Indireto Duplo Indireto Triplo

Figura 2.3: Blocos endereados por um n-i de um arquivo Unix.

Captulo 2 Sistema de Arquivos Tradicional

2.2.2.3 Gerncia do Espao Livre

2.2.2.4 Tabelas Internas

Captulo 2 Sistema de Arquivos Tradicional

Leitura Escrita Leitura

4 5 Tabelas de descritores Tabela de arquivos abertos Tabela de ns-i

Figura 2.4: Tabelas internas do sistema de arquivos do UNIX.

2.2.2.5 Buffer Cache

2.2.2.6 Unix FFS

Captulo 2 Sistema de Arquivos Tradicional

2.2.3 Armazenamento Estvel no UNIX

2.2.4 Procedimento de Recuperao do UNIX

Captulo 2 Sistema de Arquivos Tradicional