a d s a e d erick b. pdocs.computacao.ufcg.edu.br/posgraduacao/disserta... · de especiﬁcação...

UNIVERSIDADE FEDERALDE CAMPINA GRANDE

CENTRO DE CIÊNCIASE TECNOLOGIA

CURSODE PÓS-GRADUAÇÃO EM INFORMÁTICA

ANÁLISE DE DESEMPENHO DE SOLUÇÕES PARA

ARMAZENAMENTO ESTÁVEL DE DADOS

Erick B. PASSOS

CampinaGrande- PB

Julho- 2003

i

ANÁLISE DE DESEMPENHO DE SOLUÇÕES PARA

ARMAZENAMENTO ESTÁVEL DE DADOS

Erick B. PASSOS

Dissertaçãosubmetidaà Coordenaçãodo Cursode Pós-Graduaçãoem

InformáticadaUniversidadeFederaldeCampinaGrandecomopartedos

requisitosnecessáriosparaobtençãodograudeMestreemInformática.

ÁreadeConcentração:CiênciadaComputação

LinhadePesquisa:SistemasDistribuídos

FranciscoV. BRASILEIRO

WalfredoCIRNE

CampinaGrande,Paraíba,Brasil

c�

Erick B. PASSOS, Julhode2003

Resumo

Aplicaçõestolerantesafalhasfreqüentementenecessitamgravardadosdeformaestável pa-

ra garantirumacomputaçãoconfiável. Paradarsuportea esserequisito,diversasformasde

seestabilizarosdadostêmsidopropostas,comogravaçãosíncronaemdiscoereplicaçãode

dadospelarede.Ao mesmotempoquediferememarquitetura,essaspropostasdiferemem

desempenho.Nessetrabalhoestudamosdoisproblemas:i) A gravaçãoestável dedadosem

si, explorandosuaarquiteturaesuasimplementaçõesdefato,e ii) A análisededesempenho

dessassoluções,ou seja,asvariáveise formasdesecompararserviçosde armazenamento

estável dedados.Fizemosumtrabalhoabrangendoo estudodesoluções,estudodemétodos

de avaliação,a implementaçãode umasoluçãobaseadaem replicaçãode dadospelarede,

e a realizaçãodeexperimentosparaavaliar o desempenhodessaimplementaçãocomparada

a soluçõesconsagradas.Comos resultadosobtidosnosexperimentoscomprovamosa via-

bilidadedassoluçõesbaseadasemreplicaçãodedadose identificamosumasériedepontos

críticosnautilizaçãodesoluçõesdearmazenamentoestável dedados.

i

Abstract

Fault tolerantapplicationsoftenneedto stabilizedatain orderto providedependablecompu-

tation. Ideasfor servicesfor datastabilizingabound,for example:synchronousoperations

on magneticdisks,datareplicationthroughthe network, or even non-volatile RAM. This

different ideasleadto differentperformancefingerprints. In this dissertationwe focuson

two problems:i) Thestablestorageproblem,with architectureandimplementations,andii)

Theperformanceevaluationof this kind of service.Our work comprehendsthestudyof the

stablestorageproblemandsolutions,studyof methodsfor performanceevaluationof this

solutions,implementationof a network data-replicationbasedsolutionandtheperformance

evaluationof thissolutionwith theclassicones,basedonsynchronousdatawrite procedures.

With theresults,we assuretheviability of our implementationandidentify a seriesof trade

offs in stablestoragesystems.

Agradecimentos

Ao meus orientadores,Fubica, por sua orientaçãodurante o programade mestrado,

sempreobjetiva e motivante, e Walfredo, pelas suas"sacações"ecomentários,sempre

elucidativos.

À AninhaeVerapelapaciênciano atendimentoe pelasimpatia.

À meusamigosdo RecantoZen, Amâncio, Lauro, Érika, Cabelo,Cláudia, Ladjane,e

Juliana,pelosmomentosdescontraídosepelacompanhia.

Gostaria também de fazer um agradecimentoespecial a meus pais que sempre me

deramo suporte,sejaelelogísticoouemocional,emtodasasfasesdeminhaeducação.

i

Conteúdo

1 Intr odução 1

1.1 Tolerânciaa Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 AvaliaçãodeDesempenho. . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 EstruturadaDissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 ArmazenamentoEstável de Dados 6

2.1 ArmazenamentoEstável . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Implementações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Usandoumúnicodisco. . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Usandomaisdeumdisco . . . . . . . . . . . . . . . . . . . . . . 9

2.3 SistemasdeArquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 SemânticadeGravaçãoemSistemasdeArquivosPOSIX . . . . . . 11

2.3.2 Sistemasbaseadosemnós-i . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 Sistemasdearquivosbaseadosemdiáriose jornais . . . . . . . . . 14

2.3.4 Replicaçãoremotadebuffers . . . . . . . . . . . . . . . . . . . . . 15

2.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 AvaliaçãodeDesempenhodeSistemasdeArmazenamentodeDados 19

3.1 MétricasdePerformance. . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Ferramentas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 FerramentasSintéticas . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2 AvaliaçãoBaseadaemAplicações . . . . . . . . . . . . . . . . . . 24

3.3 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ii

CONTEÚDO iii

4 Implementações 26

4.1 SistemadeArquivosEXT2 . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.2 ModosdeOperação . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 ReiserFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.2 Modosdeoperação. . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 SaliusFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.1 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.2 Modosdeoperação. . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.3 ServiçodeReplicaçãodeDados . . . . . . . . . . . . . . . . . . . 36

4.3.4 ServiçodeRecuperaçãodeDados . . . . . . . . . . . . . . . . . . 37

4.4 Gravaçãoestável passoapasso. . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.1 Aberturado arquivo . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2 Alocaçãodeblocos . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.3 Gravaçãodosdadosnosblocos . . . . . . . . . . . . . . . . . . . 40

4.5 Conclusão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 ResultadoseAnálise 42

5.1 Ambientedetestes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Descriçãodosexperimentos . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.1 Experimentossintéticos . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.2 ExperimentoscomumservidorSMTP. . . . . . . . . . . . . . . . 45

5.3 Resultadoseanálise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3.1 Resultadosdosexperimentossintéticos . . . . . . . . . . . . . . . 46

5.3.2 Resultadosdosexperimentoscomum servidorSMTP . . . . . . . 61

5.4 Conclusão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Conclusão 67

A Análise EstatísticadosResultados 74

A.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

CONTEÚDO iv

A.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A.2.1 SistemadearquivosEXT2 . . . . . . . . . . . . . . . . . . . . . . 76

A.2.2 SistemadearquivosReiser. . . . . . . . . . . . . . . . . . . . . . 78

A.2.3 SistemadearquivosSalius . . . . . . . . . . . . . . . . . . . . . . 80

A.3 Gráficosdecomparação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A.4 Conclusão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Lista deFiguras

2.1 Modosdeoperaçãodeum sistemadearquivospadrãoPOSIX . . . . . . . 13

2.2 Modosdeoperaçãodeumsistemadearquivosqueutilize replicaçãoremota

debuffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Modosdeoperaçãodeumsistemadearquivosqueutilize replicaçãoremota

e detectepartiçõesnarede . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Estruturadeumnó internodo ReiserFSemumblocodedisco . . . . . . . 32

4.2 Estruturadeumnó formatadodoReiserFSemumblocodedisco. . . . . . 32

4.3 EstruturasimplificadadeumapartiçãoReiserFS. . . . . . . . . . . . . . . 33

5.1 DesempenhodosistemaExt2emgravaçõessíncronassemconcorrência. . 47

5.2 DesempenhodosistemaExt2emgravaçõessíncronascomconcorrência. . 47

5.3 DesempenhodosistemaExt2emregravaçõessíncronassemconcorrência. 48

5.4 DesempenhodosistemaExt2emregravaçõessíncronascomconcorrência. 48

5.5 DesempenhodosistemaReiserFSemgravaçõessíncronassemconcorrência 49

5.6 DesempenhodosistemaReiserFSemgravaçõessíncronascomconcorrência 50

5.7 DesempenhodosistemaReiserFSemregravaçõessíncronassemconcorrência50

5.8 DesempenhodosistemaReiseremregravaçõessíncronascomconcorrência 51

5.9 DesempenhodosistemaSaliusemgravaçõessíncronassemconcorrência . 52

5.10 DesempenhodosistemaSaliusemgravaçõessíncronascomconcorrência . 53

5.11 DesempenhodosistemaSaliusemregravaçõessíncronassemconcorrência 53

5.12 DesempenhodosistemaSaliusemregravaçõessíncronascomconcorrência 54

5.13 Desempenhocomparativo para gravaçõessíncronasde um arquivo de

32Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . . . 55

v

LISTA DE FIGURAS vi


32Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . . . 56


32000Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . 56


32000Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . 57

5.17 Desempenhocomparativo para regravaçõessíncronasde um arquivo de

32Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . . . 57


32Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . . . 58


32000Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . 58


32000Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . 59

5.21 Desempenhocomparativo do servidorde correio eletrônicocom 5 seções

abertassimultaneamente. . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.22 Desempenhocomparativo do servidorde correioeletrônicocom 10 seções


5.23 Desempenhocomparativo do servidorde correioeletrônicocom 20 seções


A.1 Evoluçãododesempenhodossistemasdearquivo semconcorrência . . . . 82

A.2 Evoluçãododesempenhodossistemasdearquivo comconcorrência. . . . 82

Capítulo 1

Intr odução

Sistemascomputadorizadossãocadavezmaisutilizadosparaguardar, processaredistribuir

informação.Como crescimentodademanda,aspessoaspassamadependerdessessistemas

parafazercompras,viajar, e emcertoscasosatéconfiama vida a essessistemas,comoem

sistemasdecontroledevôo e metrôs.Falhasnessessistemaspodemtrazerperdadetempo

e dinheiro, problemaslegais ou mesmorisco de vida. De algumaforma essessistemas

precisamevitar aocorrênciadefalhastornando-secadavezmaisconfiáveis.

As falhaspodemocorrertantoemhardware, por defeitosnoscomponentesou usofora

de especificação1, quantoem software, por imperfeiçõesna implementação.Duasaborda-

genssãousadasparatratarfalhas:i) prevençãodefalhas,ondeseprocuraevitar quefalhas

ocorram;ii) tolerânciaa falhas,ondeseprocuracontornara existênciadasmesmas,sendo

estaúltimanossaáreadeestudos.

1.1 Tolerânciaa Falhas

Podemosdizerquetolerânciaafalhascompreendeo estudodasformasdedetectarfalhasem

hardwareesoftwareedemantero bomfuncionamentodosistemamesmonapresençadessas

falhas.Ao longodosanos,umasériedeserviçosbásicostolerantesa falhasfoi idealizada.

Atravésdessesserviçosbásicos,épossível seconstruiraplicaçõesmaisrobustas.

Umaformasimplesdesetolerarfalhasemumaaplicaçãoé atravésdo usodepontosde

salvaguarda[Pan94], ondeperiodicamenteoestadoglobaldosistemaéarmazenado.Nocaso1Sistemaelétricoemsobrecargapor exemplo.

1

1.1Tolerânciaa Falhas 2

deumafalhaserdetectadaosistemapodeserrecuperadoparaumestadoanteriorconsistente.

Essatécnicaé particularmenteútil em casosde problemasquedemoramum longo tempo

paraseremcomputadosondeo prejuízode umareinicializaçãoseriacustosodemais.Para

serimplementada,necessita-sede um serviçode armazenamentoestável de dadosparase

salvarperiodicamenteasinformaçõesreferentesaoestadodosistema.

Outraimportanteabstraçãoparaa tolerânciaa falhasemaplicaçõeséo conceitodetran-

sação.Umatransaçãoé umconjuntodeoperaçõesquedeveserrealizadadeformaatômica,

ou seja,existeumaordemimplícita e apenasdoisresultadospossíveispodemseratingidos,

ou a transaçãoexecutacorretamenteou não executade maneiraalguma. Para garantira

estabilidadedasinformaçõesreferentesàstransaçõesjá realizadas,essessistemastambém

dependemdeumserviçodearmazenamentoestável dedados.

Paraessasduascategoriasdeaplicaçõestolerantesa falhaspodemosverqueum serviço

de armazenamentoestável de dadosé necessárioparasuaimplementação.A forma mais

comumdeseproveresseserviçoéatravésdautilizaçãodeequipamentosauxiliaresdearma-

zenamentotaiscomodiscosmagnéticos.Discostêmsidoutilizadospor teremum alto grau

deconfiabilidadeemcomparaçãocomoutrastecnologias,bemcomoumagrandecapacida-

de de armazenamento.As possíveis falhasqueum discopodesofrersãotratáveis através

de técnicasrelativamentesimples. Mas,apesarde seremconfiáveis,o desempenhodesses

discosnãoevolui nomesmoritmo queoutrastecnologiastaiscomoredesdetransmissãode

dadosememóriavolátil.

Essebaixodesempenhorelativo temsidocontornadopelaa maioriadasaplicaçõesatra-

vésdo usodecacheslocaisemmemóriavolátil paraotimizaro acessoa disco. Aplicações

quetêmrequisitosdedesempenhofazemusodessacacheenquantoaplicaçõesquenecessi-

tamdegarantiasdeestabilidadenasoperaçõesdegravaçãosofremaspenalidadespor conta

dobaixodesempenho.

Em certoscasosissopodenãovir a serum problemapelo fato de nemtodaaplicação

tolerantea falhaster grandesrequisitosdedesempenho.Entretanto,nosúltimosanostemos

visto um crescimentorápidonessesrequisitosemsistemasbaseadosemtransações,taisco-

mosistemason-line, por contadagrandequantidadedeoperaçõessimultâneas.Além disso,

a quantidadede dadoscarregandoa informaçãode controlede umatransaçãoou o estado

internodeumsistemaaumentouconsideravelmente.Issotemmotivadoo estudodetécnicas

1.2AvaliaçãodeDesempenho 3

alternativasparaproverestabilidadedosdados.

Comoserviçosdearmazenamentodedadossãoprovidosbasicamenteatravésde hard-

wareemconjuntocomo sistemaoperacional[Pan94], suainterfaceparaasaplicaçõesé o

conjuntodeoperaçõesdegravaçãodossistemasdearquivo. Ostrabalhosrecentesnessaárea

têm exploradoduasabordagensparaotimizar essedesempenho,sendoumadelaso proje-

to e implementaçãode novasformasde seestruturaros sistemasde arquivo [RO92; Rei;

ext; xfs; jfs; MG99] e a outraé evitar o usoimediatodo disconasoperaçõesde gravação

segura[CNC� 96; BCPS02;LGG� 91]

Nestenossotrabalho,implementamosum sistemadearquivosbaseadoemumatécnica

dereplicaçãodedadosemmemóriaremota,evitandoaspenalidadesdeperformanceobtidas

pelousoimediatodediscos[BCPS02]. Essaimplementaçãofoi usadaparaseavaliar essa

técnicade gravaçãoestável em relaçãoa outrasabordagensnessetrabalhode avaliaçãode

desempenho.

1.2 Avaliaçãode Desempenho

Partindodopontodevistadodesenvolvedordeaplicaçõestolerantesafalhassurgeumoutro

problema.Comocompararessastécnicasdiferentesde searmazenardados?Em sistemas

dearquivo, variáveiscomoconcorrênciapelousodo discoe padrãodecarga2 têm enorme

influênciasobreo resultadofinal emumacomparaçãodedesempenho.Issodecorredo fato

dediferentesformasdeseorganizarosdadose escalonaro usodo discolevama diferentes

padrõesdecomportamentodoserviço.

A forma maissimplesde semedir o desempenhodessessistemaé através do uso de

micro benchmarks, ou seja,aplicaçõesquemedemo desempenhodossistemasde arquivo

medindoo custodecadaoperaçãoindividualmenterepetidasvezes,comumacertavariação

nagranularidade,efazendoumsumáriodosresultadosatravésdemédias,variânciasepicos.

Outraformaé submetero serviçodearmazenamentoa umacargapadronizada3 e comparar

o comportamentodestenodecorrerdoprocessodegravaçãoe leituradosdadosdessacarga.

Issoéa técnicachamadademacro benchmark.2Quantidade,granularidadeevelocidadecomqueosdadoschegamaosistemadearquivos.3Cargadetrabalhoquesejaparecidacomo comportamentodecertasaplicaçõescomosistemasdebancos

dedadosou sistemasquefazemsalvaguardas.

1.2AvaliaçãodeDesempenho 4

Apesarde estarsendobastanteexploradapelaliteratura,essaáreaaindacarecede um

estudocomparativo maiscompletoqueutilize técnicasdemicro e macro benchmarkspara

obterinformaçõessobreasatuaisimplementaçõesdessesserviços.As comparaçõesexisten-

tescostumamutilizar apenasumadessastécnicasouentãocomparardoisserviçossimilares4.

Ferramentasde micro benchmarksãoboasquandosedesejaobteruma idéia geraldo

comportamentodo serviçodearmazenamentoestável dedados,massómacro benchmarks

e aplicaçõesreaissãorepresentativasemrelaçãoaospadrõesdecargaqueocorrememum

ambientedeproduçãodeumsistematolerantea falhas.

Nossotrabalhoprocuroucompararasprincipaistécnicasdeimplementaçãodeserviços

de armazenamentoestável através da utilizaçãode uma aplicaçãoreal, que utiliza arma-

zenamentoestável de dados,paraseobterum padrãode comportamentodessesserviços.

Tambémcomparamosessassoluçõesatravésdastécnicastradicionaisde avaliaçãode de-

sempenho(micro emacro benchmarks) desistemasdearmazenamento.

Nossacontribuiçãoparaa áreaé ajudaradministradoresde sistemasqueprecisamen-

contrara soluçãomaisadequadaparaseucontexto, bemcomodescobrira formapelaqual

variáveis taiscomoconcorrênciaafetamo desempenhodessessistemas.Ao final da leitura

destetrabalho,o leitor deverásercapazdeentendero funcionamentodeserviçosdearma-

zenamentoestável, entenderasdiferentesformasdeseavaliar seudesempenhoe tolerância

quantoa falhase,por fim, poderresponderàsseguintesquestões:

� Dadosumcontexto deuso5 eumpadrãodecargadeumaaplicação6, quala técnicade

armazenamentoestável dedadosmaiseficienteemtermosdecustoedesempenho?

� Quaissãoosmelhoresparâmetrosparaseavaliar a qualidadedeum serviçodearma-

zenamentoestável dedadossabendoquaissãoosrequisitosdaaplicação?

4Dois serviçosde armazenamentoestável queutilizam a mesmatécnicaparagravar os dados,sejaesta

disco,redeou memórialocalnãovolátil.5Modelodesistema,qualidadeedesempenhodo equipamentodediscoe rededetransmissãodedados.6Tamanhomédiodosarquivos, frequênciade gravação,variânciado tamanhodosblocosgravadosbem

comoseutamanho,nível deconcorrênciaobservado,etc.

1.3Estrutura daDissertação 5

1.3 Estrutura da Dissertação

Nospróximosdoiscapítulossãodiscutidososconceitosbásicose ostrabalhosrelacionados

comeste.No Capítulo2, mostraremosa definiçãoformal do queé um serviçodearmaze-

namentoestável e comoessesserviçostêmsidoimplementadosnosdiversossistemascom-

putacionais.No Capítulo3, exploraremososconceitosrelativosà avaliaçãodedesempenho

desistemasdearmazenamentodedadosemostraremoscomoosparâmetrosdecomparação

podeminfluir nosresultadosobtidos.

NoCapítulo4,detalhamosasimplementaçõesdetrêssistemasdearmazenamentoestável

dedadosqueforamutilizadasnosnossosexperimentos.OCapítulo5, trazadescriçãoformal

dos testesque foram executadose umaanálisedetalhadadosdadosobtidosdosmesmos.

Nessaanáliseestánossaprincipalcontribuiçãoparaestalinhadepesquisa.

O Capítulo6 trazalgumasobservaçõesfinaiseconcluio trabalho.

Capítulo 2

ArmazenamentoEstável deDados

Aplicaçõestolerantesa falhasfrequentementenecessitamarmazenardadosdeformapersis-

tente.Um serviçodearmazenamentoestável visa forneceressaabstraçãoparao desenvol-

vedor, deixando-olivreparatrataroutrasquestõesinerentesà tolerânciaa falhas.

Nestecapítulo,iremosdescrever o problemado armazenamentoestável dedados,e for-

malizarumaabstraçãode um serviçodessetipo quesejarobusto. Iremostambémdiscutir

asprincipaistecnologiasutilizadasparadarsuporteà armazenamentoestável dedados.Por

fim, faremosumaexploraçãodasabordagensusadasporsistemasoperacionaismodernospa-

raproveresseserviçoatravésdainterfacedearmazenamentopadrão,ossistemasdearquivo.

O objetivo destecapítuloéfamiliarizaro leitor como problemaemquestão,ilustrandoas

principaisdificuldades,assoluçõesencontradaseasabordagensmaisutilizadasporsistemas

reais.

2.1 ArmazenamentoEstável

Armazenamentoestável é umaabstraçãodeum serviçoidealparapersistênciadedadosto-

lerantea falhas.Em outraspalavras,assume-sequeo sistemacomputacionalofereceuma

formadearmazenamentoquepreserva seuconteúdomesmonapresençadefalhas[Pan94].

Comonapráticaé impossível prever todasasfalhasdehardwarequepodemocorreremum

sistemacomputacional,serviçosdearmazenamentoestável provêemumaformadetolerân-

ciasimplificada,ouseja,tolerandoapenascertostiposdefalhas.

A formamaiscomumdeseproverumserviçodearmazenamentoestável éatravésdauti-

6

2.1ArmazenamentoEstável 7

lizaçãodedispositivosdearmazenamentosecundáriosnãovoláteis,taiscomodiscosmagné-

ticos.Apesardeseremrelativamenteconfiáveis,discosnãopodemserconsideradosseguros

o suficienteparaprover armazenamentoestável no contexto demuitasaplicações,a nãoser

auxiliadospor algumatécnicaderedundância.

Paraentendercomoserviçosdearmazenamentoestável sãoimplementados,precisamos

saberostiposdefalhaqueosdispositivosfísicosdearmazenamentopodemsofrerequetipo

de eventosindesejáveis essasfalhaspodemprovocar. Processosoperamum discobasica-

menteatravésdeduasoperações[Pan94]:

� procedimentoescrever(endereço,dado)

� procedimentoler(endereço)retorna(estado,dado).

O procedimentode escritarecebedois parâmetros:i) o endereçofísico no disco,onde

osdadosdevemsergravados;e ii) osdadospropriamenteditos. O procedimentodeleitura

recebecomoparâmetroo endereçofísico a ser lido e retornaos dadosali contidose um

estadoquepodeindicarbomou ruim. Seo estadoé bomsignificaqueosdadosnãoestão

corrompidos,seretornaruim significaqueosdadoslidos estãocorrompidos.

Emboraosdispositivosfísicosatuaisjá tratemalgunstiposdefalhas,outrasnãopodem

sertratadasnestenível. As falhasmaiscomunsquepodemocorrercomumdiscosão:

� FalhasTransientes: O discosecomportadeformaimprevisível por um curtoperíodo

detempo.

� SetorDanificado: Um setordo disco é permanentementedanificadoe os dadosali

gravadossãoperdidos.

� Falha na Controladora: A controladorade discosfalha. O conteúdogravado nos

discosnãoé perdidomasfica inacessível enquantoacontroladoranãofor reparada.

� FalhadeDisco: O discoéperdidoporumafalhafísica,comoporexemploumaquebra

dacabeçadeleitura.O dadossãoirrecuperáveis.

Vamosagoraenumeraralgunsdoseventosindesejáveis provocadospor essestipos de

falhasduranteum procedimentodeleituradedados:

2.2Implementações 8

1. Erro de Leitura Simples: A leitura do endereçoa retornaestadoruim masdeveria

retornarbom porqueos dadosnãoestãocorrompidos. Issoé provocadopor falhas

transientesenãocostumaperdurarmuito tempo.

2. Erro deLeitura Persistente: A leituradeumendereçoa retornaestadoruim esucessi-

vasleiturascontinuamcomo mesmocomportamento.Issoé normalmenteprovocado

porum setordanificado(ou por umafalhano discoounacontroladora).

3. ErronãoDetectado: Endereçoaéruim masleiturasretornamestadobom, ouendereço

a é bom, masa leituraretornadadosdiferentesdaquelesqueforamarmazenados.

Se um procedimentode escritaocorrecomodesejado,ele deve mudaro conteúdodo

endereçoa parad. Entretanto,falhaspodemocorrere ospossíveiseventosindesejadossão

osseguintes:

1. EscritaNula: Conteúdodo endereçoa nãoémodificado.

2. EscritaErrada: Endereçoa passaaser(ruim, d)

Além doseventosrelacionadosa operaçõesde leiturae escrita,existemcertostiposde

eventosindesejadosque podemocorrernão estandodiretamenterelacionadoscom essas

operações,masapenascoma passagemdo tempo.Essestiposdeeventoscostumamafetar

certaspartesdodiscoecostumamocorrerinfreqüentemente.Esseseventossão:

1. Corrupção: Um endereçopassade(bom,d) para(ruim, d).

2. Recuperação: Um endereçopassade(ruim, d) para(bom,d).

3. Erro nãoDetectado: Um endereçomudade(s,d) para(s,d’)

comd �� d’

2.2 Implementações

Dependendodosrequisitosde confiabilidadeda aplicaçãoe da capacidadenecessária,um

serviçodearmazenamentoestável podeserconstruídoutilizando-seapenasum ou um con-

junto de discos. Vamosagoradescrever as formasmais comunsde se implementaresse

serviço.

2.2Implementações 9

2.2.1 Usandoum único disco

É possível seimplementarum sistemadearmazenamentoestável usando-seum únicodis-

co. Paratantovamosdescrever duasoperaçõeschamadasdeLeitura-Cuidadosae Escrita-

Cuidadosa[Pan94]:

� Leitura-Cuidadosa: Nestaoperaçãoo sistemafaz repetidasleiturasatéqueo estado

retornebomou sejaatingidoum limite no númerodeleituras.Estaoperaçãopor si só

já podecontornareventosdo tipo erro deleitura simples.

� Escrita-Cuidadosa: Nestaoperaçãoo sistemafazumaescritaseguidadeumaleitura

atéquea leituraretorneestadobom. IssoeliminaoseventosEscritaErradaeEscrita

Nula.

Atravésdessasduasoperaçõesépossível seimplementarasoperaçõesEscrita-Estávele

Leitura-Estávelquegarantemumacertatolerânciaa falhas.Paratantovamosconsiderarum

discoquenãosofraumafalhacompletae queum eventoindesejadoaleatórioafeteapenas

um certogrupode setoreschamadossetoresrelacionados.Uma unidadeestável de dados

é compostapor um pardeendereçoslocalizadosemsetoresnãorelacionadosa um mesmo

eventoaleatório. As operaçõesestáveis sobreessesendereçospodemser implementadas

assim:umaoperaçãoestável deleiturafazumaLeitura-Cuidadosadeum dosendereçosdo

par, seo estadofor ruim, faza leitura a partir do outro endereçodo par; umaoperaçãode

escritaestável fazumaEscrita-Cuidadosaemum dosendereçosdo pare emseguidafazo

mesmono endereçoseguinte.Dessaformasãoevitadososproblemascausadospor eventos

aleatórios.

2.2.2 Usandomaisdeum disco

A forma maissimplesde se implementarum serviçode armazenamentoestável de dados

usandomais de um disco é a técnicade espelhamento[Pan94]. Essatécnicafaz o mes-

mo que a implementaçãodescritana seçãoanteriorcriandounidadesestáveis compostas

por unidadesdealocaçãodedoisou maisdiscos.Dessaformapodem-seevitar problemas

relacionadosa falhascompletasdedisco.

2.3SistemasdeArquivo 10

O grandeproblemadessasoluçãoestánacargaextraimpostaatodaoperaçãodegravação

umavezqueosdoisdiscosdevemseracessadossucessivamente.Essacargaextra podeser

evitadacoma utilizaçãodemaisdeumacontroladoradediscos,aumentando-seo custodo

sistema.

Umaalternativaexistenteparamelhorara escalabilidadedeserviçosdearmazenamento

baseadosem discosmagnéticosé a técnicaconhecidacomo RAID (RedundantArray of

Inexpensive Disks) [CLG� 94]. Nessatécnicaum conjuntode discosé usadoparasimular

umúnicodisco,degrandecapacidade,atravésda“alternânciadebits”. Essatécnicaoferece

ummelhordesempenhoumavezqueleituraegravaçãodeumconjuntodebitspodeserfeita

emparalelo.Entretanto,dessaforma,o sistemanãopoderásuportarfalhasjá queum único

discodanificadopodeinviabilizara recuperaçãodainformação.

A soluçãoécolocardiscosredundantescarregandoinformaçõesdeparidadedoconjunto.

Dessaforma,afalhadeumdisconãoocasionaráperdadeinformação.Existemváriosníveis

de redundânciaquepodemserutilizadosfazendovariaro númerode falhasde discosque

podemsertoleradase tambémo desempenhomáximoquesepodeobter[CLG� 94].

2.3 Sistemasde Ar quivo

Jádiscutimoscomofalhasdediscospodemsertoleradasparaseconstruirunidadesdearma-

zenamentoconfiáveisapartirdediscosquepodemsofreressasfalhas.Agorairemosdiscutir

comoessasunidadesdearmazenamentoestáveissãoutilizadasparaseconstruirum serviço

dearmazenamentoestável dedadosnosistemacomputacional.

Ossistemasoperacionaisnormalmentefornecemumserviçodearmazenamentodedados

atravésdosrespectivos sistemasde arquivo. Parapodergarantira recuperaçãodosdados

armazenados,sistemasdearquivos têmquemanterinformaçõessobrea localizaçãodesses

dados. Essasinformações(meta-dados)tambémficam armazenadasem disco e a forma

usadaparaorganizá-lasteminfluêncianodesempenhodessessistemasdearquivo.

Paraevitar perdaexcessiva dedesempenho,sistemasdearquivo geralmenteoperamde

doismodosdistintos: i) um mododemelhordesempenho,ondenãosegarantea persistên-

cia dosdadosarmazenadoslogo apósa operaçãode gravação;e ii) um modoestável onde

o sistemagarante,a cadaoperaçãode gravação,queos dadossãoarmazenadosde forma


definitivaemumdispositivo secundário(disco).

Napróximaseçãofaremosumarevisãosobreasemânticadegravaçãodedadosfornecida

atravésdainterfacedesistemasdearquivosqueseguemo padrãoPOSIX[Org]. Emseguida

veremosalgunsdetalhessobreasprincipaistécnicasdeestruturaçãodedadose meta-dados

nessessistemasdearquivo.

2.3.1 SemânticadeGravaçãoemSistemasde Ar quivosPOSIX

Devemexistir doismodosdeoperaçãoparao procedimentodegravaçãodedadosemsiste-

masdearquivo POSIX:gravaçãoassíncrona1, nãoestável; e síncronaou estável. No modo

de operaçãoassíncrono,o sistemaoperacionalfaz usode cache em memóriavolátil para

melhoraro desempenhoda gravaçãode dados. No modode operaçãosíncronoo sistema

operacionalsófazusodacacheparaotimizara leituradosdados.Essesmodosdeoperação

podemservisualizadosnaFigura2.1.

O modode operaçãoa serusadonasgravaçõesé indicadopelaforma quea aplicação

abreo arquivo. Sea aplicaçãoabreo arquivo incluindoa diretiva O_SYNCentãotodasas

operaçõesdegravaçãosobreaquelearquivo serãoexecutadasde forma síncrona.Casoes-

sadiretiva nãosejausada,asoperaçõesserãoassíncronas.O modode operaçãosíncrono

podeserobrigatoriamenteusadocasoo sistemadearquivos tenhasidomontadocomosín-

cronoouo diretórioondeo arquivo estáarmazenadoéconfiguradoparasóaceitaroperações

síncronas.

Outraformadesegarantira estabilidadedeoperaçõesdegravaçãosobreum arquivo é

fazerusodafunçãofsync. Essafunçãorecebecomoparâmetroum arquivo e varrea cache

do sistemadearquivosprocurandoblocosmodificadosqueaindanãotenhamsidogravados

emdisco,emseguidarealizaessaoperaçãodegravaçãoemdisco.

Quandosefazusodeoperaçõesassíncronasemum sistemadearquivos,umafalhapor

paradanamáquinapodelevarainconsistênciasnessesistema.Parapodertoleraressetipo de

falha,sistemasdearquivo fazemusodeferramentasderecuperaçãodaconsistência(comoo

fsck - file systemcheck) ou técnicasdegravaçãoquemantenhama consistênciapelomenos1Na verdademodoatrasado(delayed), ondeosdadosficamgravadosemmemóriavolátil duranteum certo

intervalo detempo.No modoassíncronooriginal a gravaçãoé iniciadaimediatamentemasa aplicaçãonãoé

bloqueadaduranteesseperíodo.


dosmeta-dados.Naspróximasseçõesvamosveralgumasdasprincipaistécnicasparamanter

essaconsistência,bemcomoprovero serviçodegravaçãoestável dedados.

2.3.2 Sistemasbaseadosemnós-i

A maioriadossistemasdearquivo POSIXé derivadado sistemadearquivosdesenvolvido

parao BSD Unix, mais conhecidocomo FFS [MJLF84], e utiliza uma estruturaestática

paramanteras informaçõesrelativasaosdadoscontidosno disco. Trêsestruturasbásicas

(meta-dados)mantémo controledessainformação:

� Estrutura Super-Bloco: mantéminformaçõessobreum sistemadearquivoscomoum

todo,ouseja,informaçõessobreblocoslivres,númerodearquivosentreoutras.

� Estrutura nó-i: mantéminformaçõessobreum arquivo específico.Entreessasinfor-

maçõesdestacam-setamanho,ponteirosparablocosde dados,datade modificação,

informaçõessobreusuárioegrupodonosdo arquivo entreoutras.

� Estrutura Entrada-de-diretório:Faz a ligaçãoentreum caminhode arquivo e o nó-i

correspondente.

Paraentendercomoessesmeta-dadospodemseralteradospor operaçõesdeescritaso-

bre arquivos e a importânciada ordenaçãodessasoperaçõespodemosusardois exemplos

básicos:

Exemplo1: Umaaplicaçãoabreumarquivo eacrescentacercade10Kbytesdedadosao

mesmo,sendoqueo tamanhodeblocodo sistemadearquivo é 8Kbytes.Paracorretamente

alocaros 10Kbytesextras,o sistemade arquivos deve alocarpelo menosmaisum bloco,

gravar osdadosno mesmoe criar um ponteiroparaesseblocono nó-i do arquivo. Casoos

dadossejamgravadosfisicamenteemdisco(noblocorecentementealocado),maso nó-i não

tenhasidocompletamentearmazenadoemdisco,umafalhano fornecimentodeenergia fará

comqueessesdadossejamperdidos,umavezqueo sistemanãotemcomolocalizaro bloco

ondeestãoosdadosnaausênciadoponteirorelativo aomesmononó-i doarquivo.

Exemplo2: Umaaplicaçãocriaumarquivo temporárioedepoismoveessearquivo para

seudestinofinal2. Essaoperaçãoconsisteemmodificarasentradasdediretório. É preciso2Essaé a operaçãobásicausadapor editoresdetexto parasalvar arquivose servidoresdee-mailparalidar

commensagensrecebidaseencaminhá-lasaseusdestinoslocais


removeraentradadodiretóriotemporárioqueapontaparao arquivoecriarumanovaentrada

no diretóriodestinodo mesmo.Casoa entradatemporáriasejaremovida antesdanova ser

criadae ocorrauma falha geral do sistema,o arquivo serádefinitivamenteperdido. Isso

exemplificaa importânciadaordenaçãoentreoperaçõesdesistemasdearquivos.

Essasoperaçõessobremeta-dadose a importânciade suaordenação,juntamentecom

a distribuiçãoespacialdessasinformaçõesao longo do disco,causamsériosproblemasde

desempenhonessessistemasdearquivosbaseadosemnós-i. Poressemotivo, grandeparte

dasimplementaçõesdessessistemasdearquivosfazusodecachingparamelhoraro desem-

penhodasoperaçõesde escritasobrearquivos, quandorequisitosde estabilidadenãosão

necessários.

requisi−

confiabilidade

escrita sincrona

disco

leitura

escrita assincrona

performance

aplicaçao

to?

cache deleitura egravacao

cache de

Figura2.1: ModosdeoperaçãodeumsistemadearquivospadrãoPOSIX

A grandemaioria dos sistemasde arquivos baseadosem nós-i provê armazenamen-

to estável através da sincronia dessasoperaçõessobre dadose meta-dados[MJLF84;

CTT94]. Aplicaçõesque necessitamde estabilidadenasoperaçõesde escritasofremde

umasériedeproblemasdedesempenhoprovocadospor essanecessidadedesincronianes-

sasoperações[GP94]. Além disso,problemascomoconcorrênciaeo baixodesempenhodos

discosmagnéticos,quandocomparadoscomoutrastecnologiasdearmazenamentoe trans-

missãodedados,taiscomomemóriavolátil e redes[CP93a], tornamessasoluçãoinviável


em certoscasos.O usode arraysde discoscomosoluçãopodeminimizar esseproblema

maséumasoluçãoquetemlimitaçõesdeescala.

Naspróximasseçõesvamosver algumastécnicasparaminimizar a carga de trabalho

extra parasegravar osmeta-dadosrelativosa operaçõesdeescritaemsistemasdearquivo

POSIXbaseadosemdiscosmagnéticos.

2.3.3 Sistemasde arquivosbaseadosem diários e jor nais

Umasoluçãopropostaparaminimizara perdadedesempenhodesistemasdearquivo base-

adosemnós-ifoi a utilizaçãodesistemasdearquivosbaseadosem logs, ou diários[RO92].

Nessetipo de sistemade arquivos, dadose meta-dadossãogravadosseqüencialmentenas

operaçõesde escrita,evitando-seo excessode movimentaçãodascabeçasde gravaçãodo

disco. Informaçõessuficientessãomantidasemmemóriaparafacilitar a buscae recupera-

çãodeinformaçãoapartir dessediário.

Paramantero sistemaconsistenteenãosobrecarregaracapacidadedodisco,umproces-

sode limpezaé periodicamenteexecutadobuscandoinformaçõesquesejamredundantese

procurandodesfragmentaro disco.Esseprocessodelimpezaéo grandeproblemadossiste-

masdearquivosbaseadosemdiáriosporqueé extremamenteineficientee aomesmotempo

necessárioemsistemasdearquivo comgrandecargadeutilização.

Umadassoluçõespropostasparalidar comesseproblemafoi a utilizaçãodessesdiários

no sistemade arquivos, masapenasparaoperaçõesem meta-dados.Essessistemasque

usamum diário (ou jornal) paragravar as operaçõessobremeta-dadossãochamadosde

sistemasdearquivo jornalados(journaledfile systems)[jfs; xfs; ext; Rei]. Nessessistemas,

qualqueroperaçãosobremeta-dadoségravadanessediárioantesdesergravadaemdiscona

suaestruturaoriginal garantindoestabilidadenasoperaçõessobreessesmeta-dadosmesmo

quandoarmazenamentoestável não é um requerimento.O diário só conteminformação

relativaa operaçõessobremeta-dados,a estabilidadedosdadosemsi aindadependedo uso

degravaçãosíncronanessessistemasdearquivos.

Sistemasde arquivos baseadosem nós-i sofremde outro problemaalém da perdade

desempenho.Elessãoincapazesde lidar com arquivos ou discosmuito grandes.Com o

atualdesenvolvimentocomputacionaldemandandocadavezmaisrecursos,entreelesuma

grandeagilidadee capacidadenossistemasdearmazenamento,essessistemasbaseadosem


nós-iestãosetornandoobsoletos.

Parasuportararquivose discoscadavezmaioresumaopçãoé a modificaçãodasestru-

turasexistentes,como mapasde blocoslivres,adicionando-semaisbits paralidar com a

informaçãoextra. Entretanto,essasoluçãonãoé muito escalável, devido à formalinearque

essasestruturasguardamasinformações.Mapasdebitsmuitoextensosobviamentelevama

ummaiortempogastocadavezquesetemdegravaralgumainformaçãonosmesmos.Além

disso,paradasno fornecimentodeenergia, ou falhasdo sistemaoperacional,podemlevar a

inconsistênciasnosistemadearquivosdevido àmaioriadasaplicaçõesdeusuáriooperarem

de modoassíncrono.Tradicionalmente,esseproblemaeratratadoatravésde um processo

dechecagemrealizadosemprequeo sistemaoperacionalé reiniciadoapósumapaneines-

perada,eperiodicamenteparaprevenir falhasnosistemadearquivos.Esseprocedimentode

checagemprecisavarrertodaapartiçãodediscoembuscadeinconsistências.Como grande

aumentodecapacidadedosdiscosatuaisesseprocedimentoépordemaislentoepodeatrasar

consideravelmenteo processodeinicializaçãodosistema.

Nossistemasbaseadosemjornal a checagemdedisconainicializaçãoé substituídapor

um procedimentomaissimples,quelê a informaçãocontidano diário de operaçõessobre

meta-dados,fazendoascorreçõesnecessáriasparacolocaro sistemaemum estadoconsis-

tente. Essessistemasde arquivo tendema ter umaligeira perdade desempenhoem certas

operaçõesassíncronaspor causada carga extra provocadapelo usodo diário. Entretanto,

elesgarantemumamaiorestabilidadedosistemadearmazenamentoeumprocessoderecu-

peraçãomaiságil.

2.3.4 Replicaçãoremotade buffers

Soluçõesde armazenamentoestável de dados baseadasna replicaçãoremota de buf-

fers[BCPS02;LGG� 91] sãoumaoutraalternativaparaotimizarodesempenhodeaplicações

quenecessitamdesseserviço.A idéiaconsisteemreplicar-seremotamenteemmemóriaos

dadose meta-dadosreferentesa operaçõesde gravaçãoestável submetidasao sistemade

arquivos,paragarantirtolerânciaa falhaspor crashdamáquinaondeessasoperaçõesestão

sendoprocessadas,e mesmoassimevitar a perdadeperformanceobtidaquandoseutiliza a

gravaçãosíncronaemdiscos.


Ar quitetura

Como já vimos anteriormente,um sistemade arquivos tradicionaloperade duasformas:

aplicaçõesquenãorequeremestabilidadedosdadosgravadospodemusarummododemaior

performanceondeos dadosenviadosparagravaçãoficam em memóriaatéqueo sistema

possagravá-losemdiscosemprejudicaro desempenhodamesma.Aplicaçõesquerequerem

estabilidadedosdadosgravadosutilizam a formadegravaçãosíncrona,ondeosdadossão

enviadosdiretamenteparao discobloqueandoa aplicaçãoatéqueessaoperaçãotenhasido

finalizada.EssesmodosdeoperaçãopodemservisualizadosnaFigura2.1.

Um serviçobaseadona replicaçãode buffers tentaevitar a perdade performancepro-

vocadapela forma de gravaçãosíncronautilizandoa memóriade máquinasremotaspara

prover tolerânciaa falhas,e, localmente,gravaçãoassíncronaparaprover desempenho.Os

modosdeoperaçãodeum sistemadearquivosqueutiliza essasoluçãopodemservistosna

Figura2.2.

requisi−

disco

escrita assincrona

performance confiabilidade

Serviço de replicaçao de dados (SRD)

to?

aplicaçao

estaçoescache deleitura egravaçao operaçoes de

leitura eupdate

remotas

Mecanismo dereplicaçaode dados operaçoes

de update

Figura2.2: Modosdeoperaçãodeum sistemadearquivosqueutilize replicaçãoremotade

buffers

Essasoluçãoassumequea redenãopodecorrompermensagensmaspodeatrasarar-

bitrariamenteo envio e a entrega dasmesmas.A redetambémpodeeventualmenteestar

particionadadeformaqueareplicaçãonãosetornepossível emumdadomomento.O siste-


madevedealgumaformadetectaressapartiçãoeencontrarumaformaalternativademanter

a estabilidadedosdados.Osmodosdeoperaçãodeum sistemaquesejacapazdedetectar

partiçõesnarede3 estárepresentadonaFigura2.3.

requisi−

partiçao?

disco

escrita assincrona

performance

aplicacao

to?

SRD

confiabilidade

sim

escrita sincrona

leituracache de

naocache deleitura egravaçao

Figura2.3: Modosde operaçãode um sistemade arquivosqueutilize replicaçãoremotae

detectepartiçõesnarede

Sistemasdearquivo edemaissoluçõesdearmazenamentoestável dedadosqueutilizam

replicaçãoremotadebuffersdependemdeumprocedimentoderecuperaçãodedadossempre

queocorramdefalhasnofornecimentodeenergiaounosistemaoperacionaldaestaçãoonde

os dadosestavam sendoarmazenados[BCPS02;LGG� 91]. Emboraapresentempequenas

diferençasna forma de sereplicaros dados,sejapor espelhamentoou alternânciade bits,

todasessassoluçõesexecutamum procedimentoderecuperaçãodedadosqueprocura,nas

demaisestaçõesquecompõemo serviçode replicação,por dadose meta-dadosqueeven-

tualmentenãoestejamaindaestabilizadosemdisco,damesmaformaqueo escalonadordo

sistemadearquivosvarrea cachedememóriavolátil embuscadeblocosnãogravadosem

disconumsistemadearquivos local. Apósa execuçãodesseprocedimentoderecuperação

essessistemasdearquivo estãoconsistentese atualizadoscomosúltimosdadosqueforam

gravadospelasaplicaçõesestáveisantesdafalha.3Partiçõesreaisouvirtuaisprovocadaspelaquedado desempenho.

2.4Sumário 18

2.4 Sumário

Nestecapítulomostramososprincipaisproblemasa seremcontornadosparasedesenvolver

sistemasdearmazenamentodedadostolerantesa falhas.Apresentamostambémcomolidar

comasfalhasquepodemocorrercomosdispositivosfísicosmaisusadosparaseimplemen-

tar tal serviçocriandoumsistemadearmazenamentotoleranteaessasfalhas.

Porfim, vimoscomosistemasdearquivosseutilizamdessessistemasdearmazenamento

físico paraproverumainterfacedearmazenamentodeobjetos(arquivos)paraasaplicações

de usuários.Mostramosasprincipaisformasde organizaçãoutilizadasparasearmazenar,

buscare recuperaressesobjetose asimplicaçõesno desempenhodecadaumadessasalter-

nativas.

Capítulo 3

AvaliaçãodeDesempenhodeSistemasde

ArmazenamentodeDados

Temosacompanhadonasultimasdécadasum crescimentoespantosonacapacidadedepro-

cessamentodosmicrochips. Essecrescimentocria umatendênciade seconsiderara velo-

cidadedosprocessadorescomoa principal,quandonãoa única,métricadeperformancede

umsistemacomputacional[CP93a].

Comparadascomosprocessadores,quetêm evoluídoemum ritmo bastanteacelerado,

tecnologiasde armazenamentode dadostêm se desenvolvido a passoslentos[CLG� 94].

Comisso,armazenamentoe recuperaçãodedadostendeasetornarcadavezmaiso gargalo

paramuitascategoriasde aplicações.Mais que isso,essadiferençade desempenhoentre

processadoresedispositivosdearmazenamento,tornamaperformancedosúltimoscadavez

maisrelevantenaavaliaçãogeraldaqualidadedeumsistema.

A importânciado estudodemétricase ferramentasdeavaliaçãodedesempenhoé, por-

tanto, uma conseqüênciadessediferenteritmo de evoluçãodessastecnologias. Existem

diversasferramentase técnicasparaavaliar o desempenhode serviçosde armazenamen-

to de dados,gerandoresultadostanto distintosquanto,certasvezes,conflitantes. Algu-

masidéias,entretanto,foram setornandoconsensona literatura,comopor exemplo: uma

ferramentade avaliaçãode desempenhodesistemasdearmazenamentode dadosidealde-

ve impor ao sistemaumacarga semelhanteàquelaqueserásubmetidapor usuáriosreais,

paraajudardesenvolvedoresa identificaros principaispontosde falha[CP93a;SFGM93;

Mil96]. Além disso,essasferramentasdevemajudaradministradorese usuáriosa entender

19

3.1MétricasdePerformance 20

melhoro comportamentodessessistemas,auxiliandonahoradeumacompra.

Nestecapítulo,vamosexploraressesdoisaspectosdaavaliaçãodedesempenhodesis-

temasde armazenamentode dados:métricasde performancee representatividadedasfer-

ramentasexistentesemrelaçãoàscargasaplicadasa essessistemasem ambientesreaisde

produção.

3.1 Métricas de Performance

Porenvolver um grandenúmerodevariáveis,aleatóriasou não,a avaliaçãodedesempenho

parasistemasde armazenamentopodeserfeita atravésde um grandenúmerode métricas.

Ao sefazerum estudode performancede sistemasde armazenamentoestável de dados,é

fundamentalentendero queessasmétricasavaliam e comoasdiversasvariáveis afetamo

resultadodasmesmas.

A principalmétricaconsideradaparaessessistemasé a vazão.Estapodesermedidade

duasformas[CP93b;CP93a]:

� Taxadeentradae saída:Normalmentemedidaemnúmerodeoperaçõesdeentradae

saídapor unidadedetempo;

� Taxadefluxo dedados:Normalmentemedidaemnúmerodebyteslidos ou gravados

porunidadedetempo.

Taxade entradae saídaé normalmenteusadaquandosedesejaprever a performance

de um sistemade armazenamentode dadosao ser submetidoa aplicaçõesque executam

muitasoperaçõesem curtosperíodosde tempo,sendocadaumadelassobreumapequena

quantidadede dados,comopor exemploservidoresde correioeletrônicosobrecarregados,

ou aplicaçõesbaseadasem transações.Taxa de fluxo de dadosé mais adequadaparase

ter umaidéiado desempenhodeaplicaçõesquetrabalhamcomgrandesvolumesdedados,

comoaplicaçõescientíficasouaplicaçõesbaseadasemsalvaguardaspor exemplo.

Entretanto,métricasqueavaliam apenasa vazãodosdadosnãosãosuficientesparase

comparara performancededoissistemasdearmazenamentoporque,dependendodo requi-

sito da aplicação,nãoadiantaum sistemaser capazde armazenarum volume imensode

3.1MétricasdePerformance 21

dadosem apenasalgumaspoucasunidadesde tempose leva tambémessemesmotempo

paraarmazenarumapequenaquantidadededados.

A segundamétricamaisimportante,portanto,éo tempoderesposta,ou latência[CP93a;

CP93b]. Essamedidaindicaquantotempoo sistemaleva paraacessarou iniciar umagra-

vaçãode dados. Essamétricaé normalmenterelacionadaà avaliaçãode performancede

leiturasmastambémtemgrandeimportânciaparasistemasbaseadosemtransaçõesquene-

cessitamdeum sistemadearmazenamentoquesejacapazdegravar pequenasquantidades

dedadossimultaneamente.

Essasduasmétricassãocomplementaresporquediscosmagnéticos,por causade sua

arquiteturadeacessoàmídiadegravação,secomportamdeformasdistintasdependendoda

formadegravaçãousada:seqüencialoupor intervalos.Quandoacessadosseqüencialmente,

casomaiscomumdeseocorreremsistemasquearmazenamgrandesvolumesdedadosde

umavez, discosatingemos seuspicosde desempenho.Quandoacessadosem intervalos,

comopor exemploem aplicaçõesbaseadasem transações,a cabeçade gravaçãotem que

sereposicionara cadaoperação,aumentandoa latênciae, por conseqüência,diminuindoa

vazão.

Capacidadedearmazenamentotambémé umamétricaimportanteparaadministradores

de sistema,principalmentequandolevadaem consideraçãojunto com o custoinerenteao

equipamento.Gráficosdedesempenhoecapacidadesãomuitoúteisparacomparaçãoquan-

do analisadosemparaleloaocustodo sistema.Secapacidadeou custonãofossemmétricas

importantes,os sistemascomputacionaisjá teriamdeixadode usardiscosmagnéticosem

detrimentodeoutrasformasdememórianãovolátil, comoflashmemory. Entretanto,essas

formasalternativase rápidasde memórianãovolátil têm um alto custoparacadabytede

capacidadequandocomparadascomosdiscosmagnéticos[CP93b].

A última métricaimportanteparasistemasde armazenamentode dadosé a confiabili-

dade. Essaé umamétricade muita importânciaparasistemasde armazenamentoestável

de dados.Normalmente,fabricantesexpressamessamedidaatravésdo tempomédiopara

falha, queinformaa expectativadetempoútil deusodo equipamentoantesqueessevenha

asofrerumafalha.No presentetrabalho,vamosconsiderarqueo tempomédioparafalhade

umdiscoésuficienteparaatendernossosrequisitosdeconfiabilidade.

Algumasdessasmétricassãotriviais deseremcomparadas,taiscomoo custoe a capa-

3.2Ferramentas 22

cidade.As restantessãopor demaisinfluenciadaspeloambientedeexecuçãoeasdiferentes

cargasde trabalhoaplicadasaosistemade formaqueumaavaliaçãocriteriosasetornane-

cessária.

Na próxima seçãovamosanalisaraspectosde metodologiase ferramentasúteis para

avaliaro desempenhodesistemasdearmazenamentoestável dedados.

3.2 Ferramentas

Diversostrabalhostêmsidopublicadosapresentandoe avaliandotécnicase ferramentasde

avaliaçãodedesempenhoe qualidadedeequipamentoscomputacionais.Ainda nãoseche-

goua um consensosobrea formaidealdeseavaliar um sistemadearmazenamentoporque

paracadaperfil deusoqueo sistemavenhaa sesubmeter, umametodologiadiferentedeve

seraplicadaparaseavaliarseudesempenho.Nestetrabalhofocamosanossaanálisenaava-

liaçãodedesempenhodesistemasdearmazenamentoestável dedadossobo pontodevista

deum administradordesistemas,maisespecificamenteum administradordesistemasonde

asseguintescategoriasdeaplicaçõespredominam:sistemasbaseadosemtransações,servi-

doresdecorreioeletrônicoe servidoresdearquivo. Nossaanálise,portanto,estarávoltada

paraferramentase técnicasquesejamúteisa essacategoriadeusuários.

Existeumasériede característicasquesãodesejáveisem umaferramentade avaliação

de desempenhode um sistema. A principal delasé que essaferramentadeve ajudarde-

senvolvedorese usuáriosa entenderpor que o sistemase comportada maneiraque vem

fazendo[CP93a;CP93b]. Outracaracterísticaimportanteé quea ferramentade avaliação

devecorretamenterepresentaracargadeusoqueo sistemavai sofrerquandoestiver instala-

do. Dessaforma,pode-seprevercommaisacuráciaessecomportamento[SFGM93;Mil96;

CP93a;CP93b;MS96;MK].

É comumo usode medidasfornecidaspelosfabricantesdosequipamentosde armaze-

namento,comodiscospor exemplo,parailustrar o funcionamentode sistemasde armaze-

namentodedados.Entreessasmedidasestãotempomédiodeacesso,taxadetransferência

nominaldo sistemadearmazenamento,etc.Essamedidaspodemtrazeralgumainformação

inicial, masajudampoucoa prever o comportamentode tais sistemasem um ambientede

produção[CP93b;CP93a].

3.2Ferramentas 23

Uma boa ferramentade avaliaçãode desempenhodeve poderisolar razõesparabaixa

performancee assimajudardesenvolvedoresa melhoraressessistemas.Para tanto,essas

ferramentasdevem ser limitadaspelasoperaçõesde entradae saída. Em outro caso,ou-

tros fatorespodemestarinfluindo naavaliaçãodesejada.Em certoscasos,entretanto,uma

ferramentanãolimitadapor entradaesaídapodeserútil, comoveremosmaisadiante.

Emboraessaclassificaçãonãosejaunanimidade,vamosconsiderara existênciadedois

tiposprincipaisdeferramentasparaavaliaçãodedesempenhodesistemasdearmazenamento

estável de dados: i) ferramentassintéticas,tambémchamadasde micro benchmarks; e ii)

ferramentasbaseadasemaplicações[CP93b].

3.2.1 FerramentasSintéticas

As ferramentassintéticasutilizam o sistemade armazenamentoinvocandodiretamenteas

chamadasdesistemarelativasa leitura,gravaçãoemodificaçãodosdadosemedindoo custo

dessasoperações.Por invocaressasfunçõesdiretamente,essasferramentastêmumamaior

capacidadedeseremlimitadaspor essasfunções,o queé umacaracterísticadesejável para

essacategoriadeferramentas.

Medidasimportantesque podemser avaliadasatravés dessacategoria de ferramentas

incluem:

� Taxadevazãodosistemadearquivos;

� Latênciarelativaa todasasoperações;

� Influênciadeconcorrênciae fragmentaçãodosdados1 sobreaperformance.

A principal limitaçãodessasferramentasestáno fato dequeapesarde seremlimitadas

por operaçõesdeentradae saída,elasnãoestãorealizandonenhumtrabalhocomputacional

prático,ouseja,nãorepresentambemnenhumacategoriadeaplicaçãoreal,sendoassimpou-

coúteisparaprevero comportamentodossistemasemumambientedeprodução[SFGM93;

Mil96].

Algunsprojetossedestacamentreessasferramentas,entreessespodemoscitar:1Distribuiçãoespacial,nodisco,dosváriosblocosdedadosquecompõemumobjeto,comoumarquivo por

exemplo.

3.2Ferramentas 24

� Bonnie[Bra] - Ferramentaqueaplicaumasériedecargasdetrabalhosobreum único

arquivo incluindoleituras,gravações,acessosconcorrentes,entreoutrascoisas;e

� IOStone[PB90] - Ferramentademicro benchmarkbaseadaemcargasdeuso2 deesta-

çõesdetrabalhoobservadasemambientesdeprodução.

� IOZone[Nor] - Ferramentaflexível, portável paraumagrandevariedadedesistemas

operacionaisquepermitefazeravaliaçõesdeoperaçõessíncronas.

Essasferramentassãoúteisprincipalmenteparaprojetistasquedesejamentendero com-

portamentodossistemasde armazenamentosobdeterminadacarga específica,massãode

poucaajudaparaadministradoresquenecessitamescolherentreumsistemaeoutroparauti-

lizaçãoporqueascargasreaisaqueumsistemaserásubmetidosãomuitomaisvariáveisque

aquelassubmetidasporessasferramentas.

3.2.2 AvaliaçãoBaseadaem Aplicações

A utilizaçãodeaplicaçõesreaisparaavaliar o desempenhodesistemasde armazenamento

trazavantagemdesepoderrepresentarcommaispropriedadeacargaaqueo sistemadeverá

sersubmetidoem um ambientede produção. Issoé feito pelo usode diversasaplicações

comocompiladores,bancosdedados,editores,emvariadascombinaçõesdeformaasimular

umsistemaemprodução.

Essetipo deavaliaçãodedesempenhotemo potencialdeajudarbemmaiso administra-

dor naescolhadeumsistemadearmazenamento.Entretanto,aescolhadacargadetrabalho

a seraplicadaé um aspectomuito importanteparao resultadofinal e tem sido objetode

estudodediversostrabalhos[SFGM93;Mil96].

Outro problemaencontradonessetipo de avaliaçãoé decorrentedo fato de quemuitas

vezesessasaplicaçõesreaisnãosãolimitadaspelasoperaçõesdeentradaesaída,mascarando

os resultados.Um cuidadodeve ser tomadona instrumentaçãodessasaplicaçõesparase

tentarmedirapenaso queé relevanteparaa avaliaçãoemquestão.Essaé, entretanto,uma

característicadesejável deumaferramentadeavaliaçãoemcertoscasos,comoo dopresente2Apesardebaseadaemcargasreais,essaferramentaaindaé consideradasintéticapor fazera mediçãode

performancedasoperaçõesindividualmente.

3.3Sumário 25

trabalho,porqueajuda-nosa encontrarquãorelevanteum ganhode desempenhoé obtido

ao semudarde um sistemaparaoutra. É interessantedescobrirqual o ganhopráticoem

desempenhoqueumsistemacomótimosresultadosobtidosatravésdeferramentassintéticas

vai provocarquandosubmetidoa um testede carga com umaaplicaçãoreal quenãoseja

totalmentelimitadapor operaçõesdeentradaesaída.

3.3 Sumário

Nestecapítulo,abordamoso problemada avaliaçãode desempenhode sistemasde arma-

zenamentode dados,primeiramentemostrandoa suarelevânciafrenteao diferenteritmo

de evoluçãono desenvolvimentodosdispositivos de armazenamentoe de processamento.

Identificamosasprincipaismétricasquesãoimportantesparaessaavaliaçãoe mostramos

algumasformasdecombiná-lasparaseformarresultadosilustrativos.

No final, classificamosasferramentasusadasparaessefim emduascategoriasbásicas,

ferramentassintéticase aplicações.Emboraessaclassificaçãonãosejaumaunanimidade,

ela ilustra de forma simplesos dilemasencontradospor aquelesquedesejamrealizaruma

avaliaçãodessetipo.

No próximocapítuloiremosanalisarasimplementaçõesdesistemasdearquivo quefo-

ramusadasnestetrabalho,focandoessaanálisenasemânticadearmazenamentoestável.

Capítulo 4

Implementações

Nosdoiscapítulosanterioresprocuramosintroduziro leitor no contexto desistemasdear-

mazenamentoestável dedadosedemetodologiasusadasnaavaliaçãodessessistemas.Neste

capítulo,vamosapresentaralgunsdetalhesde trêsimplementaçõesdesistemasdearquivo,

queprovêemarmazenamentoestável dedados,usadascomoreferênciaeanalisadasemnos-

sotrabalho.

Vamosanalisaraestruturaqueessessistemasdearquivo utilizamparaorganizarseusda-

doseoscorrespondentesmeta-dados,focandoessaanálisenoimpactoprovocadonodesem-

penhodosmesmos.Tambémseráexploradaasemânticadegravaçãoestável dosmesmos.

Os sistemasutilizados foram o Linux EXT2 [CTT94], o ReiserFS[Rei] e o Sa-

liusFS[BCPS02]. O EXT2 é o sistemade arquivos padrãoparao popularsistemaopera-

cional Linux e é um sistemabaseadoem nós-i comoo FFS[MJLF84]. O ReiserFSé um

sistemadearquivosmoderno,baseadoemárvoresbalanceadas,queutiliza técnicasdejornal

paramelhorara eficiêncianarecuperaçãodefalhas,e finalmenteo SaliusFS,quefoi imple-

mentadopor nósparaestetrabalhoa partir deum projetoanterior[Sta]. O SaliusFSé um

sistemadearquivosbaseadonocódigodoLinux EXT2 eutiliza replicaçãoremotadedados

pelaredeparaprover tolerânciaa falhas.

4.1 SistemadeAr quivosEXT2

O sistemadearquivosEXT2 [CTT94] (SecondExtendedFile System)foi desenvolvido para

ser utilizado pelo sistemaoperacionalLinux e é uma evoluçãodo ExtendedFile System,

26

4.1SistemadeArquivosEXT2 27

que por suavez foi desenvolvido a partir do sistemade arquivos do sistemaoperacional

Minix [Tan87].

O principal objetivo no desenvolvimento do sistemade arquivos EXT2 foi adicionar

novas funcionalidadese remover limitaçõesexistentesno sistemade arquivos do Minix.

Essaslimitaçõesrestringiamo tamanhodo sistemade arquivos,o tamanhodosnomese o

númerodearquivosa valoresmuito pequenosparaum sistemaoperacionalcomo potencial

doLinux.

Como a maioria dos sistemasde arquivo paraLinux, o EXT2 traz uma sériede ca-

racterísticasbásicasderivadasde outrossistemasde arquivo paraUNIX [MJLF84; Tan87;

MK]. Arquivossãorepresentadospor umaestruturachamadanó-i, diretóriossãoarquivos

contendoumalistadeapontadoresparaoutrosarquivos.

Iremosagoraexplicaraorganizaçãoestruturalbásicadosdadosemeta-dadosnosistema

dearquivosEXT2.

4.1.1 Organização

A estruturadedadosbásicadeum sistemadearquivosEXT2 é o superbloco.O superbloco

é umasequênciafixa debytesgravadosno início decadapartiçãoEXT2. O tamanhodessa

sequênciadependedo tamanhoda partiçãoe do númerode blocosexistentesna mesma.

Além dacópiaprincipalno início decadapartição,existemcópiasdebackupdosuperbloco

distribuídasaolongodamesma.

No superblocoficamgravadasinformaçõessobreo tamanhodecadablocodedados,o

númerodeblocosenós-iexistentesnapartição,alémdedoismapasdebits: umparaindicar

autilizaçãodosblocosdedadoseum paramarcarosnós-i livres.Além dessasinformações

estruturais,o superblocomantéminformaçõessobreo tipo de sistemade arquivos, última

datademontagem,entreoutrasinformações.

Um nó-i contémas informaçõesrelativas a um arquivo individual no sistema. Essas

informaçõesincluemo id dousuário,o id dogrupo,dataehoradoúltimo acesso,dataehora

daúltimamodificação,entreoutras.Além disso,estãononó-i osapontadoresparaosblocos

dedadosdo arquivo. Essesapontadoressãodetrêstipos:

� ApontadoresDiretos:sãoponteirosparablocoscontendodados.


� ApontadoresIndiretos:sãoponteirosparablocoscontendoapontadoresdiretos.

� ApontadoresIndiretosDuplos: sãoponteirosparablocoscontendoapontadoresindi-

retos.

Diretóriossãoarquivos especiaisquecontêmumalista de nós-i com um nomede ar-

quivo paracadaum. Sãoorganizadosdeformahierárquica.Quandoo sistemarecebeuma

requisiçãoparaum caminhode arquivo, faz a pesquisaa partir do diretório raiz, cujo nó-i

estáindicadono superbloco,atéencontraro nó-i correspondenteaoarquivo. Essenó-i fica,

então,armazenadona memóriae chamadasde localizaçãosubsequentesnãoexigem mais

acessodiretoàsestruturasno disco.

4.1.2 ModosdeOperação

O sistemadearquivosEXT2 fazusointensodememóriavolátil paraotimizaro seudesem-

penho. O uso de cache de leitura é útil em todo caso,maso uso dessamemóriavolátil

nasoperaçõesde gravaçãode dados,ou modificaçãode meta-dados,podecomprometera

confiabilidadedo sistema.

Existemdoismodosbásicosdeoperaçãoparao sistemadearquivosEXT2 nasoperações

degravaçãosobreum arquivo, dependendodo usoou nãodecacheemmemóriavolátil: i)

modosíncrono,ondetodasasoperaçõesdegravaçãosobremeta-dadosedadossãogravadas

diretamenteemdiscoantesdaaplicaçãoqueassolicitouserdesbloqueada;e ii) modoassín-

crono,ondeo sistemafazusodecacheparaotimizaraperformancedasoperações,inclusive

degravação,comprometendoaconfiabilidade.

Para se garantirque os dadosgravadosestejamestáveis apóso término da operação

é necessárioqueos mesmossejamgravadosem discoantesdo desbloqueioda aplicação.

Existemquatroformasdesegarantirestaestabilidade:

� UtilizandoadiretivaO_SYNCnaaberturadoarquivo - Essadiretivagarantequetodas

asoperaçõesdegravaçãosobreessearquivo serãorealizadasdeformasíncrona;

� Fazendogravação assíncronae em seguida executando-sea chamadade sistema

fsync(fd)- Essachamadade sistemagrava em disco todosos dadose meta-dados

modificadosnoarquivo indicadopor fd;


� Montando-setodoo sistemadearquivoscomosíncrono- É possível forçarquetodas

asoperaçõesdegravaçãosobreumsistemadearquivossejamfeitasdeformasíncrona

desdequeessaopçãosejaindicadano momentodamontagem;

� Adicionando-sea diretiva de sincroniano diretório que contémo arquivo que está

sendoutilizado- Dessaforma,todososarquivosdaquelediretóriosecomportamcomo

setivessemsidoabertoscomadiretivaO_SYNC.

A semânticaoriginal do FFS [MJLF84] indicava que todasas operaçõessobremeta-

dadosdeveriamsersíncronas,independentementedo usoou nãodecacheparaa gravação

dos dadosem si. Entretanto,essasemânticaresultava em um desempenhomuito baixo

nessesistemade arquivos, de forma que a grandemaioria dasnovas implementaçõesde

sistemasdearquivosbaseadasno FFSrelaxaramessasemânticaemfavor do desempenho.

RecentesimplementaçõesdoFFSparao sistemaoperacionalFreeBSD1 trazemumatécnica

alternativa,denominadasoftupdates[MG99], paraasemânticadegravaçãodosmeta-dados.

Nessatécnica,asoperaçõessobremeta-dadosnãosãogravadasdiretamenteemdisco,ficam

armazenadaslogicamenteem um grafo organizadosatravés de um esquemaescolhidono

momentoda criaçãoda partição. Periodicamente,o escalonadordo sistemade arquivos

grava operaçõessobremeta-dadosno disco,seguindoasdiretivasapontadaspelo esquema

do grafo. Taisdiretivaspodemserpróximasdasemânticaoriginal, ou seja,levandoa uma

atualizaçãoquasesíncronadosmeta-dados,ou mais relaxada,levandoa um desempenho

superiormasaindagarantindopelo menosconsistênciano sistemade arquivos atravésda

ordenaçãodasoperaçõessobreosmeta-dados[MG99].

Existemuita controvérsiaentreos desenvolvedoresde sistemade arquivos e desenvol-

vedoresde aplicaçõestolerantesa falhassobreos prejuízosem confiabilidadeprovocados

por esserelaxamentode semântica.Como essetópico extenderiademaisnossotrabalho,

preferimosestudarapenaso casoondeessasemânticanãoérelaxada,ouseja,apenasaplica-

çõesqueutilizam gravaçãosíncronaoperamsobreosdiretóriosondeexecutamososnossos

experimentos.1SistemaoperacionalbaseadonalicençaGPLdesenvolvido porvoluntáriosatravésdainterneteorganizado

naUniversidadedaCaliforniaemBerkeley - www.freebsd.org.

4.2ReiserFS 30

4.2 ReiserFS

O sistemade arquivosReiserFSé um projetodesenvolvido utilizando-setécnicasde siste-

masgerenciadoresde bancosde dadosem sistemasde arquivos. O objetivo principal dos

desenvolvedoresdessesistemadearquivosé trazerganhosdedesempenhoparaaplicações

quetrabalhamde forma semelhantea SGBDs,ou seja,aplicaçõesqueoperamsobreuma

grandequantidadedearquivospequenossemprejudicaraperformanceparaoperaçõessobre

arquivosgrandes.

Tradicionalmente,se achava que objetospequenos(arquivos entreeles)deveriam ser

tratadosem outra camada,quenãoo sistemade arquivos, porqueo custode seotimizar

asoperaçõessobreessesarquivos pequenoscomprometeriao desempenhodossistemade

arquivos nasoperaçõessobrearquivos grandes.Dessaforma, pequenosobjetos(registros

emumabasededados)sempreforamtratadospor SGBDse a pesquisanessaáreaapontou

o usodeárvoresbalanceadascomoa melhorestruturaparaorganizarosmesmos.

O desenvolvimento do sistemade arquivos ReiserFStem mostradoque, incluindo-se

modificaçõesespecíficasparaum sistemade arquivos, algoritmosde arvoresbalanceadas

podemtornareficienteo processamentode pequenosobjetosdiretamentepelo sistemade

arquivossemcomprometero desempenhodasoperaçõessobrearquivosgrandes[Rei].

TodaaestruturaorganizacionaldoReiserFSéumaárvore,assimcomoo EXT2, estando

agrandediferençanofatodequenoEXT2,essaárvoreéestática,rigidamentedependenteda

hierarquiadediretórios,do tamanhodosblocose dadisposiçãodosmesmos.No ReiserFS

essaárvoreé balanceadae osnósdamesmasãoordenadospor umachavequeé partecom-

ponentedosmeta-dadosde cadaobjeto(diretório, arquivo, ou nó internoda árvore). Pelo

fatodequetodososgalhosdessaárvoreteremexatamenteamesmaprofundidadeespera-se

umganhogeraldedesempenhoaoserealizaroperaçõesdeleituraegravação.

O ReiserFSé tambémmaiseficienteem termosde utilizaçãode espaço.Sabemosque

quantomaior o bloco de dadosde um sistemabaseadoem nós-i, melhorseudesempenho

em termosde performance,masmaior se tornao desperdíciode espaçotodavez queum

arquivo nãopreencheum blocointeiro comseusúltimosbytesdedados.No ReiserFSisso

é evitadodeduasformas:i) existemblocosdedadosnãoformatados,ou seja,semtamanho

fixo. Sãousadosparaguardarsequênciasmaioresque4kbytesde um arquivo; ii) existem

4.2ReiserFS 31

blocosformatadosqueservemparaguardarasporçõesfinaisdemaisdeumarquivo, ouseja,

osúltimosbytesdeum arquivo podemestarcompartilhandoum blococomo final deoutro

arquivo paraevitar desperdíciodeespaço.

Da mesmamaneiraquesistemasdearquivosbaseadosemnós-i,o ReiserFSfaza loca-

lizaçãode um arquivo específicovarrendoa árvore do topo paraos galhos. Existemduas

diferenças,entretanto:i) No EXT2 um galhopodecrescerindefinidamente,dependendodo

númerodesub-diretóriosexistentesparaencontraro arquivo, e ii) No ReiserFSumamesma

chave poderepresentarmaisdeum arquivo, casoessessejampequenos.Existemuitacon-

trovérsiaentrepesquisadoresseo usodeárvoresbalanceadasé eficienteou nãonestecaso,

umavezqueminimizao tamanhodosgalhosdessasárvores.Esperamosencontraralgumas

respostascomnossosexperimentosdescritosno capítulo5.

Além disso,o ReiserFSé um sistemadearquivosbaseadoemjornal,o quetornadesne-

cessáriaaexecuçãodeumprocedimentodechecagememcasodereinicializaçãoprovocada

por umapaneinesperada.

VamosagoraanalisarasestruturasinternasdoReiserFS.

4.2.1 Organização

UmapartiçãoReiserFSéumaárvorebalanceadaondecadablocodessapartiçãoéumnóda

mesma.Existemtrêstiposdenós:

� Nó interno- Nós internosnãocontémdados,armazenamponteirosparasub-árvores.

O blocoraiz dapartiçãoinformaqualé o nó internodemaisalto nível no momento.

Semprequeseprecisaaumentaro tamanhoda árvore adiciona-seum nó internono

topodamesma;

� Nó formatado- Nósformatadosé a estruturaondesearmazenamitensdo sistemade

arquivose suaschavesdepesquisa.Itenspodemserdequatrotipos: i) Item indireto,

ii) Item direto,iii) Item estático,ou iv) Item dediretório;

� Nó nãoformatado- Sãoosúltimosnósdosgalhosdaárvoreecontémdadosdearqui-

vosmaioresque4Kbytes.

4.2ReiserFS 32

O númerodeitensagrupadosemumnóformatadoévariável,dependendodotamanhode

cadaum delese do tamanhodosblocosnapartição.Apenaso tamanhomáximodosgalhos

naárvoreéfixadono momentodacriaçãodapartição,sendoseuvalorpadrão5 (cinco).

A Figura4.1mostraaestruturadeumnó internodaárvore.Essesnósnãocontémdados

e asúnicasinformaçõesexistentessãoasreferênciasa outrosnóse asrelativaschavesde

pesquisa.No cabeçalhodoblocofica armazenadoo seunúmero,esuachavedepesquisa.

Cabeçalho do bloco Chave 0 Chave 1 Chave N Ponteiro 0 ... Espaço livrePonteiro N+1

Figura4.1: Estruturadeumnó internodoReiserFSemumblocodedisco

A Figura4.2 representaa estruturade um nó formatado. Essesnósarmazenammeta-

dadosdearquivosediretóriosepodem,também,armazenarpequenasquantidadesdedados

dearquivos.Oscabeçalhosdeítensarmazenamaschavesdepesquisadosmesmoseindicam

o tipo deinformaçãocontidanessesítens.Essasinformaçõespodemser, alémdemeta-dados

de arquivos e diretórios,entradasde diretório ou dadosde arquivos pequenosentreoutras

coisas.

Cabeçalho do blocoCabeçalhode Item 0

Cabeçaçhode Item 1

Cabeçalhode Item N Espaço livre Item N Item 1 Item 0......

Figura4.2: Estruturadeumnó formatadodo ReiserFSemumblocodedisco

Comofoi visto anteriormente,os itensarmazenadosem nósformatadospodemserde

quatrotipos:

� Item de dadosestáticos- Estetipo de item armazenaas informaçõesequivalentesa

um nó-i no UFS [RT74], ID do donoe grupodo arquivo, númerode links, datade

modificação,tamanho,permissõesetc;

� Itemdireto- Armazenaosdadosdearquivospequenos;

� Item indireto - Armazenaum grupode ponteirosparanósnão formatadosparaum

arquivo grande;

4.2ReiserFS 33

� Itemdediretório- É o equivalenteaumblocodedadosdeumdiretório,armazenauma

tabelacontendonomesde arquivos e suascorrespondentesestruturasde meta-dados

paralocalização.

Na Figura4.3 podemosver umarepresentaçãosimplificadada hierarquiadessasestru-

turasno ReiserFS.O nó raiz da árvore estárepresentadopor (1); um ponteiroparaum nó

formatadopodeservisto em(2); (3) é um item indireto,contendoum ponteiroparaum nó

nãoformatadodedadosrepresentadopor (4).

.............................DADOS.......................................

No interno principal

Nos internos

Nos formatados

No nao formatado

...

...

...

Chaves

Chaves

Cabeçalhos deItens Item indireto

Espaço livre

Item

1

2

3

4

Figura4.3: EstruturasimplificadadeumapartiçãoReiserFS

4.2.2 Modosdeoperação

O ReiserFS,assimcomoo EXT2, podeseracessadodeduasformasdistintas:i) modoas-

síncrono,ondeseusacachedeleiturae gravação;e ii) modosíncrono(seguro),ondeseusa

cacheapenasparaleituradedados.Da mesmaformaqueo EXT2, o ReiserFSsofrepena-

lidadesno desempenhoquandoestáoperandodeformasíncrona,entretanto,comoa forma

de distribuiçãodos meta-dadose dadosnessesdois sistemasde arquivos difere bastante,

esperamosencontrardiferençasdeperformancenosnossosexperimentos.

4.3SaliusFS 34

4.3 SaliusFS

O sistemadearquivosSaliusfoi projetadocomoobjetivodeotimizarodesempenhonasope-

raçõesdegravaçãoestável atravésdareplicaçãoremotadedados.Esseprojetofoi apresen-

tadocomoumadissertaçãodemestrado[Sta] e tevesuaimplementação[BCPS02] realizada

por nósparapossibilitaraelaboraçãodestetrabalho.

Essaimplementaçãofoi baseadano códigodo sistemadearquivosEXT2 encontradona

versão2.2.19do núcleodo sistemaoperacionalLinux. Por serderivadodessesistema,o

Saliuscompartilhaa maior partedo códigocom o sistemaEXT2, adicionando-se,apenas,

asfuncionalidadesnecessáriasparaprover a replicaçãode dados,evitar o usode gravação

síncronaemanteraconsistênciadessasoperações.

Um sistemadearquivosSaliusFSémontadosobreumapartiçãoEXT2 normal,compar-

tilhando,portanto,a mesmaestruturadeorganizaçãodedadose meta-dados.Parasuportar

amesmasemânticadegravaçãodosistemadearquivosEXT2, algumasfunçõesbásicas,co-

mofile_write(),fsync(),open()forammodificadasparaincluir a replicaçãoremotadedados

semprequeestabilidadefosseumrequisitodaaplicação.

O funcionamentobásicodoSaliusFSpodeserdefinidoassim:semprequeo requisitoda

aplicaçãofor estabilidadedosdadosnagravaçãoutilize gravaçãoassíncronaparamelhorar

a performancee garantaa estabilidadeusandoo serviçodereplicaçãoremotadedadosem

memóriavolátil.

4.3.1 Organização

O sistemadearquivosSaliusFSfoi implementadoa partir do códigodo sistemaEXT2 en-

contradono núcleodo sistemaoperacionalLinux nasuaversão2.2.19. Poressemotivo, o

códigodosdoissistemaé semelhante,diferindoapenasnospontosondeforaminseridasas

funçõesrelativasà replicaçãodedados.

Todasasestruturasde discodo SaliusFSsãoidênticasàquelasdefinidasparao EXT2.

Por essemotivo o SaliusFSdeve ser montadosobrepartiçõesEXT2. Na próxima seção

vamosexplicar adiferençanosmodosdeoperaçãoentreosdoissistemas.

4.3SaliusFS 35

4.3.2 Modosdeoperação

O sistemaSaliusFSdasuporteaosmesmosmodosdeoperaçãodo sistemaEXT2, masim-

plementaessafuncionalidadede maneiradistinta. Assim comono EXT2, existemquatro

formasdeseestabilizarosdadosdeumarquivo: usandogravaçãosíncronaatravésdadireti-

vaO_SYNC, marcandoo diretóriocomosíncrono,montandotodaapartiçãocomosíncrona,

ougravandodeformaassíncronaeexecutando-seachamadadesistemafsync(fd)aofinal da

operação.

Paraastrêsprimeirasformasdegravaçãoo sistemaSaliusFSoperadaseguinteformaa

cadaexecuçãoda chamadade sistemawrite(fd,dados):Os dadossãogravadosno arquivo

deformaassíncrona inicialmente,apóso queo sistemaenvia atravésdeUDP multicastum

pedidodereplicadosdadosgravados;apósteremsidorecebidassuficientesconfirmaçõesde

replicaso sistemadesbloqueiaaaplicaçãoquesolicitouagravação.

Paradarsuporteàquartaformadeseestabilizarosdados,atravésdachamadafsync(fd)o

sistemaSaliustevedesofrerumaadaptaçãoespecialquegerouumapequenalimitação.Não

havia forma de sediferenciaruma aplicaçãoqueestava usandogravaçãoassíncronapara

depoisestabilizaros dadosatravésde fsync(fd)daquelasqueusavam gravaçãoassíncrona

por nãousaremgravaçãoestável. A opçãodeseimplementara estabilizaçãodosdadosno

momentodachamadafsyncerapor demaiscustosae teve desercontornada.A alternativa

foi usarreplicaçãode dadosnasgravaçõesassíncronase criar umachamadafsync(fd)que

nãorealizaoperaçãoalguma.Dessaforma,garantimosa estabilidadedosdadosgravados,

maspenalizamosasaplicaçõesquenãoprecisamdessaestabilidade.

Essaalternativa foi necessáriaparase dar o suportea essaforma de estabilizaçãode

dados,queé muito usadapor certascategoriasde aplicações,inclusive por servidoresde

correioeletrônico. Espera-sequeessasformasde gravaçãoqueutilizam apenasmemória

volátil e replicaçãoemredetenhamumaperformancemelhorqueaquelaapresentadapelas

soluçõesbaseadasemgravaçãosíncronaemdiscoparaestabilizaçãodedados.

Naspróximasseçõesvamosdetalharum poucomaisa formade implementaçãodo sis-

temaSaliusFS,explicandoosmecanismosdereplicaçãoe recuperaçãodedados

4.3SaliusFS 36

4.3.3 Serviço deReplicaçãodeDados

O serviçode replicaçãode dadosimplementaum protocoloquegarantea estabilidadedos

dadosoperaçãoa operaçãoatravésdecópiasremotasemmemóriavolátil ou gravaçãosín-

cronasemprequea replicaçãonãoestiverdisponível. O serviçodependededuasinstâncias

básicas:o cliente(núcleodo sistemaoperacionalcom suportea SaliusFS),máquinaonde

estábaseadoo sistemadearquivosemdisco;e um grupodeservidores,quesãoaplicações

(Daemons) queexecutamemmáquinasremotas.

Osservidoresficambloqueadosaguardandomensagensvindasdosclientes.Essamen-

sagenspodemserdedoistipos:

� Pedidoderéplica:nessamensagemo clienteenvia um blocodedadosparaserarma-

zenadonoservidor, o servidordeverespondercomumamensagemdeconfirmaçãose

amensagemtiversidocorretamenterecebidaearmazenada.

� Pedidoderecuperação:o servidordeveresponderessamensagemenviandoosblocos

replicadosemsuamemória,referentesa o clientequeenviou a mensagemderecupe-

ração.

Essesservidoresguardamosblocosprovenientesdosclientesremotosemumalista en-

cadeada,mantendoinformaçõesde tempode permanênciadasmesmas.Paraevitar queo

servidoresgoteasuacapacidadedememória,umprotocolodelimpeza,descritonaespecifi-

caçãodosistemadearquivosSaliusFS[BCPS02], éexecutadodeformaaexcluir dadosnão

maisnecessáriosemantersegurosdadosaindapotencialmentevulneráveis.

Osclientesoperamdaseguinteforma: todavezqueumaoperaçãodegravaçãoseguraé

requisitada,osdadossãoinicialmentegravadosdeformaassíncronanosistemadearquivos,

ou seja, são, na maioria dos casos,armazenadosem memóriavolátil local. Após essa

gravação,essesdadossãoenviadosparao grupodeservidoresatravésdeUDP multicast. O

cliente, entãoesperaum númeromínimodeconfirmaçõesdequea réplicafoi armazenada

nosservidores,paraentãodesbloquearaaplicação.

Casoo númerode réplicasnãosejaatingido,o sistemaesperaum tempomáximopor

maisrespostaseseessasnãochegam,procedeagravaçãodosdadosdeformasíncronapara

garantirsuaestabilidade.

4.3SaliusFS 37

Esseprotocologarantequeosdadosreferentesa umagravaçãofiquemsegurospor esta-

rem presentesem um grupode máquinasatéquepossaserarmazenadoemdisco. Quanto

maioro númeroderéplicasexigido, maiora confiabilidadenasoperaçõesdegravação.

4.3.4 Serviço deRecuperaçãodeDados

Casoocorraumafalhanamáquinahospedeiradosistemadearquivos,levandoaumareinici-

alização,um procedimentoderecuperaçãodosdadosremotosprecisaserexecutado.Como

nãoé possível sabera priori seexistemou nãodadosreplicadosqueaindanãotenhamsido

gravadosem discode forma seguratorna-senecessáriaa execuçãodosseguintesprocedi-

mentosdechecagem:

� Envio deumpedidoderecuperaçãopor partedo clienteparao grupodeservidoresde

replica(UDP Multicast);

� Aguardopela chegadade todasas mensagensvindasdos servidoresde replica até

que todosos servidoresdo grupo tenhamenviado uma mensagemindicandoa não

existênciadenovasréplicas;

� Ordenaçãodasréplicasrecebidaspelotimestampexistentenasmesmas;

� Gravaçãoseguradosdadosemeta-dadoscontidosnessasreplicasemdisco;

� Envio demensagemindicandofim daoperaçãoderecuperaçãoparao grupodeservi-

doresderéplicaparaqueo espaçoocupadoporessasréplicassejaliberado.

Como,emcadamensagemdereplicação,sãoenviadostodososmeta-dadosrelativosao

arquivo, esseprotocologaranteque,apósa execuçãoda última mensagemde replicação,

os meta-dadosserãoos mesmosvistospelaaplicaçãono momentoda última operaçãode

gravaçãoestável. Observe queparagarantira estabilidadedosmeta-dados,é precisouma

operaçãodegravaçãoestável sobreo arquivo. Casotenhasido feita umaoperação,de for-

maassíncrona,exclusivamentesobremeta-dados,o protocolonãogarantea estabilidadeda

mesma.

Paravalidaresseprotocoloderecuperaçãodedados,foi implementadaumaferramenta

queusamosna inicializaçãodo sistemasemprequeo mesmotiver sido desligadoaciden-

talmenteou estejaserecuperandodeumafalhapor crash. Estaferramentaseencarregade

4.4Gravaçãoestávelpassoa passo 38

enviar a mensagemde pedidode recuperaçãoao grupode replicas,ordenarasmensagens

recebidaseescreverosdados,deformasegura,emdisco.

Foramexecutadosdoisconjuntosdeexperimentosparaseverificaro funcionamentoda

ferramentaderecuperaçãodedados.No primeiro,umaaplicaçãogravava,sequencialmente,

100Kbytesdedadosemum arquivo de texto de formasegura. Em seguida,a máquinaera

desconectadada alimentaçãoelétrica,forçando-seumaparadasemelhantea umafalhapor

crash. Ao sereiniciar, foi verificadoquedecada5 execuções,em4 o arquivo nãohavia sido

estabilizadoaindaem disco. A ferramentade recuperaçãoera,então,executada,inclusive

noscasosem queo arquivo já havia sido estabilizadoantesda parada,paraqueos dados

fossemrecuperadosa partir dasréplicas. Foi observadoque,em todosos experimentoso

arquivo foi totalmenterecuperadopelaferramenta.

Um segundotipo deexperimentofoi executadoparaseverificaracapacidadedosistema

dearquivo Saliusdelidar comaplicaçõesconcorrentes.Doisaplicativosidênticos,iniciados

simultaneamente,gravavam dados,de forma segura,sobreum sistemade arquivos Salius.

deformasemelhanteaoexperimentoanterior, amáquinaeradesligadaabruptamente,impe-

dindoo sistemadeestabilizarosdadosemdisco. Novamentea ferramentaderecuperação

conseguiu recuperarosdadosdosdiferentesarquivosemtodasastentativas.

4.4 Gravaçãoestável passoa passo

Nestaseçãovamosexplicar com algunsdetalhescomofuncionaumagravaçãoestável em

cadaum dostrêssistemasdearquivosparatermosumaestimativa do custorelativo a cada

passo.

4.4.1 Abertura do arquivo

Semprequeumaaplicaçãoabreum arquivo, sejasomenteparaleitura,sejaparagravação,

algumasoperaçõessãorealizadas. Casoo arquivo não exista, ele deve ser criado, caso

exista,deve serlocalizadonaestruturadediretóriose ter osseusmeta-dadoscarregadosna

memória.

OssistemasEXT2 e SaliusFSutilizam a mesmasestruturasdedisco,portantorealizam

essasoperaçõesda seguinte forma: i) o arquivo é localizadona estruturade diretóriosde


forma linear, partindo-sedo diretório raiz até chegar ao sub-diretórioondeo arquivo se

encontra. Essaoperaçãopodeser um poucolonga casoo arquivo se encontredentrode

umaestruturade diretóriosmuito complexa com váriosníveis. Casoo arquivo nãoexista

o primeiro passoé procurarno superblocopor um nó-i livre e alocaro mesmoparaesse

arquivo. Em seguida,osmeta-dadosdessearquivo devemsergravadosno nó-i alocado.O

último passoé a localizaçãodo diretórioondeo arquivo vai sergravadoe a geraçãodeuma

entradadediretórioapontandoparao arquivo. Observequeessaoperaçãopodeserrecursiva

casoo diretórionãoexistaaindaeprecisesercriadoemtempodeexecução.

Parao sistemadearquivosReiserFSasoperaçõessãoasmesmas,estandoa grandedi-

ferençaapenasna localizaçãodo diretório queé realizadaem umaárvore balanceadacom

profundidadeconhecidanãomaiorquecinco,por definição.Dessaforma,evitam-selongos

procedimentosdelocalizaçãoemestruturasdediretórioscomprofundidadesgrandes.As es-

truturasdemeta-dadosdoReiserFSincluemumainformaçãoamaisasergravada,achavede

pesquisa,masnessemomento,issoaindanãodeve comprometerseudesempenho.Observe

que,casoaárvoreatualestejasaturada,todoumnovo braçodevesercriado,adicionando-se

inclusive um novo nó raiz. Issoocorrecom frequênciaem umapartiçãoReiserFSrecém

formatadaqueaindanãoestápreenchidacomarquivos.

No sistemaSaliusFSessasoperaçõespoderiamserexecutadasdeformaassíncrona,mas

por questõesde consistênciano sistemade arquivos, foram mantidasde forma síncronajá

queespera-sequenãotenhamumimpactotãograndenaperformance.

4.4.2 Alocaçãode blocos

Após o arquivo ter sido abertoou criado e suasestruturasde meta-dadosestaremtodas

carregadasnamemória,inclusiveosponteirosparao nó-i, superblocoediretórios,osblocos

paragravaçãodedadosdevemseralocados.Observe queessaoperaçãopodeserrealizada

deduasformas:i) Mudando-setemporariamenteo offsetdo arquivo paraqueo sistemapré-

aloqueespaçoparaagravaçãodosdados,e ii) Alocando-seosblocosemtempodeexecução

dasoperaçõesdegravaçãoemsi, ondeosblocossãoalocadospassoa passodeacordocom

o espaçodemandadoacadaoperação.

Cadaoperaçãodealocaçãodeespaçoparaum arquivo requerasseguintesmodificações

deestruturasno sistemaEXT2: Marcação,no mapadebits deblocoslivresdo superbloco,


dosblocos,necessáriosparaa gravaçãodaquantidadede dadosrequisitada,comousados;

criaçãodeum ponteiroparaessebloco,no nó-i do arquivo, ou emum ponteiroindireto;e a

gravaçãononó-i doarquivo do novo offset.

No sistemaReiserFSessaoperaçãorequera mesmagravaçãono mapade bits do su-

perbloco,a gravaçãodosponteirosparaosblocosnaestruturaequivalenteaonó-i e o novo

offset. Até aquiessaoperaçãofoi semelhantenosdois sistemas,entretantoo ReiserFSpo-

de alocarum único bloco de tamanhograndeparasegravar os dados,funcionalidadeque

osoutrossistemadearquivo nãooferecem.Issopodelevar a umamelhorperformancena

gravaçãodedadoscomblocospreviamentealocados.

No sistemaSaliusFSessepassonão requernenhumaoperaçãodireta em disco, visto

quea informaçãocontidanasreplicaspoderecuperarosdadosnecessáriosà realizaçãodo

mesmo.

4.4.3 Gravaçãodosdadosnosblocos

Nessepasso,o sistemadearquivos já teve o espaçoalocadoparaa gravaçãodosdadose a

únicatarefa restanteéagravaçãodosmesmos.

Paraum sistemadearquivosEXT2 issoocorrenaseguinteordem: i) osdadossãogra-

vadosnosblocosnecessários,observequeno casodeumaoperaçãodegravaçãosobreuma

quantidaderelativamentepequenade dados( 32Kbytes) issopodelevar à alocaçãoe gra-

vaçãoemoito ( 8 ) blocosdiferentes.emum sistemafragmentadopelousoissopodelevar

a um custorelativamentegrande. O último passoé a gravaçãodo novo offsetno nó-i do

arquivo.

No sistemaSaliusFSa operaçãode gravaçãoocorrede forma assíncrona,nãonecessi-

tandodenenhumaoperaçãoemdisco,a nãosernasfasesanteriores.É nessemomentoque

a replicaçãodedadosocorre.Inclusiveo novo offsetnãoé efetivamentegravadono nó-i até

queocorraumasincronizaçãoprogramadapeloescalonadordedisco.

No sistemaReiserFSessepassocorrespondeà gravaçãoefetiva dosdadosnosblocos,

entretantoobserve quemesmoumagravaçãode umaquantidaderelativamentegrandede

dados( 256Kbytespor exemplo) podeserefetuadaemumúnicoblocosequencialcasoeste

tenhasidopréalocado.

4.5Conclusão 41

4.5 Conclusão

Nestecapítulofizemosumaanálisedasimplementaçõesdos trêssistemasde arquivo que

foramutilizadosemnossostestes.

Mostramosasdiferentesestruturasorganizacionaisqueessessistemasde arquivo utili-

zamparamanterasinformaçõesreferentesaosdadosgravadose a semânticade gravação

estável de cadaum deles. Certostópicos,comopor exemploa semânticade gravaçãode

meta-dadosem operaçõesassíncronas,sãobastantecontroversose exigem umadiscussão

extensademaisparaserincluídanestetrabalho.Preferimos,portanto,considerarapenaso

casoondeseutiliza exclusivamenteoperaçõessíncronas.

No final do capítuloincluímosumaanálisepassoa passodeumaseqüênciadegravação

de dadosnos trêssistemasde arquivo. Identificamos,nessaanálise,os pontoscríticosde

utilizaçãodedisconostrêssistemase possíveismelhoriasparao sistemaSaliusFS.Vamos

agoraapresentaros experimentosrealizadossobreos sistemasparaestudaro desempenho

dosmesmos.

Capítulo 5

ResultadoseAnálise

Nestecapítuloiremosdescrever osexperimentosqueforamconduzidosparaavaliar a per-

formancedossistemasdearmazenamentoestável escolhidos.Tambémiremosapresentaros

resultadosobtidosnessesexperimentoseanalisaressesresultadoscomo objetivo demelhor

entendero funcionamentodessasabordagensparaarmazenamentoestável dedados.

Inicialmente,iremosdescrevero ambientedetestesutilizado.Emseguida,faremosuma

descriçãodetalhadadosdoisprocedimentosdeavaliaçãodedesempenho,explicandoo ob-

jetivo específicodecadaumdeles.

Na segundapartedo capítuloexplicaremososdetalhesdosresultadosobtidosem cada

teste,fazendoumaanálisedosmesmos.

5.1 Ambiente de testes

Nossoambientedetestesconsistiu-sedeumaredelocal demicrocomputadoresdo tipo PC

comaseguinteconfiguração:

� ProcessadoresAMD Duron800MHz

� 128MbytesdememóriaRAM (tempodeacessode5ns)

� Discosrígidosde20Gbe5400RPM

� Adaptadoresderedeethernetde100Mbits/segundo

42

5.2Descriçãodosexperimentos 43

Osmicrocomputadoresestavaminterligadosatravésdeum barramentocompartilhado1

de 100Mbits/segundo,isoladode qualqueroutrafonte de tráfego. Comoapenasos micro-

computadoresusadosnostestesestavamligadosaessebarramento,pudemosmanteracarga

submetidaà redesobcontrole.

Todososmicrocomputadoresestavamexecutandoo sistemaoperacionalRedHat Linux

7.2 com o kernel2.2.19-salius2 e nenhumserviçode rededesnecessáriofoi iniciado,evi-

tando,assim,a ocorrênciade tráfego extra na redee concorrênciaexcessiva pelo usodos

processadores.

Osmicrocomputadoresestavamorganizadosdaseguinteforma:

� Um microcomputadorprincipalondeossistemasdearquivo eramtestados;

� Dois (2) microcomputadoresexecutandoservidoresdereplicaçãoSalius;

� Um microcomputadorusadoparainserircarganaredeenomicrocomputadorprincipal

atravésdeNFS;

� Um microcomputadorparagerarascargasparao servidorSMTPe mediro desempe-

nhodo mesmosobo pontedevistadocliente.

5.2 Descriçãodosexperimentos

Dois conjuntosdeexperimentosforamexecutadosnessaavaliação:o primeiroconsistiude

avaliaçõessintéticasbaseadasemferramentasdemicro-benchmarkparasistemasdearquivo

e o segundoconsistiuda comparaçãodo desempenhode um servidorSMTP, que utiliza

armazenamentoestável, executandosobreostrêssistemasdearquivo sobavaliação.

Paraosexperimentossobreo sistemade arquivosSalius,restringimossuaoperaçãoao

seguintecaso:doisservidoresdereplicaçãoexecutandoe o clienteaguardandoapenasuma

confirmaçãode armazenamentoremoto. Essaescolhafoi baseadanos resultadosobtidos

previamentequemostraramessecomosendoo casomédionacurva dedesempenhodesse

sistema[BCPS02]. A variânciaentreoscasossemprefoi estatisticamentedeseconsiderável

deformaqueentendemosessarestriçãocomonãoprejudicialàvalidadedosresultados.1HUB semcomutaçãodeframes2Kernel2.2.19customizadocomo suporteaosistemadearquivosSalius.


5.2.1 Experimentossintéticos

O objetivo desseconjuntodeexperimentosé ajudara compreendercomodiversasvariáveis

(tamanhodearquivose deregistros,intervalo entreoperaçõesetc.) influenciamno desem-

penhodasoperaçõesdegravaçãoestável nossistemasdearquivo testados.

Dividimosesseconjuntodeexperimentosemduasetapas:

1. Avaliaçõeslivresdeinterferênciaexterna

2. Avaliaçõescominterferênciaexterna

Naprimeiraetapaossistemasdearquivosforamtestadosemumambientelivredequal-

querinterferênciaquepudesseafetaro desempenhodasoperaçõesdegravaçãoestável, ou

seja,nãoexistia concorrênciapelo usodo disco,da rede,ou do processador. Nessaetapa

avaliamosa influênciadasvariáveis relacionadasdiretamentecom a operaçãode gravação

emsi, ouseja,tamanhodosarquivose registrosutilizados,etc.

Na segundaetapaprocuramosentendera forma comointerferênciasexternasafetamo

desempenhodessessistemasde armazenamentoestável. Paratestara influênciado acesso

concorrenteaodiscoe à redeexecutamosscriptsemumamáquinaremotaquemontava um

diretório da máquinaprincipal de testesatravés de NFS e executava operaçõesde leitura

e gravaçãosobreessediretório gerandoumacarga de uso. Tal carga consisteem 80% de

leiturase 20%degravações.As gravaçõesforamfeitasatravésdo comandoscat enviando

o conteúdodeum arquivo pequeno(64Kbytes)previamentecriadoemoutrodiscoparaum

novo arquivo no discoondesedesejava criar a cargadegravação.As leituraseramobtidas

atravésdo mesmocomandosendoquea partir do discoondesedesejava criar a carga de

leitura. O script criou essascargasalternandoentregravaçõese leiturasnasproporções

indicadase remontandoo sistemade arquivos periodicamenteparaevitar o usoexclusivo

da memóriacache do sistemaoperacional.Comoo sistemade arquivos sendotestadona

máquinaprincipaleraexportadoatravésdeNFSpudemoscombinaro acessoconcorrenteà

redeeaodiscoemapenasumainstânciadeexperimentos.

A ferramentautilizadaparaesseconjuntode testessintéticosfoi o IoZonebenchmark

tool 3. As duasetapasdetestessintéticosforamexecutadasdaseguinteforma:3www.iozone.org


Cadasistemadearquivosa seravaliadopassoupor umabateriadeexperimentosondea

influênciadasseguintesvariáveiseraobservada:

1. Tamanhodo arquivo (32,320,3200e32000Kbytes)

2. Tamanhodo registrodegravação(2, 4, 8, 16 e32Kbytes)

3. Forma de alocaçãodos blocosde arquivo (pré alocadosou alocadosem tempode

execução)

Emseguida,amesmabateriadetesteseraexecutadasimultaneamentecomo usodeNFS

paramedira influênciadautilizaçãoconcorrentedosistemadearquivos.

5.2.2 Experimentoscomum servidor SMTP

Resultadosobtidosatravésdeferramentasdeanálisesintéticasnosdãoumavisãogeraldo

comportamentodossistemas.Sãoúteisparaentendermoscomodiversosfatoresalteramo

desempenhodetaissistemas.Entretanto,nemsempreessasferramentasrepresentamcorre-

tamenteacargaàqualessessistemasseriamsubmetidosemambientesdeproduçãoreais.

Nossaidéiafoi avaliar a performancedeumaaplicaçãorealqueusaarmazenamentoes-

tável dedados,aosersubmetidaaumacarga,obtidapreviamenteatravésdomonitoramento

dessamesmaaplicaçãoemum ambientedeprodução.Escolhemosum servidordecorreio

eletrônicopor serumaaplicaçãobastantecomumquetem um comportamentosemelhan-

te a um sistemabaseadoem transaçõesno quediz respeitoà utilizaçãode um sistemade

armazenamentoestável.

As cargasa quesubmetemoso nossoservidorSMTPdetesteforamobtidasa partir dos

logsdeutilizaçãodo servidoranjinho.dsc.ufpb.br entreosdias17 defevereiroe 30 deabril

de2002.Comparamosesseslogscomoutroslogsdeservidoresdecorreioeletrônicoobtidos

daLight InfoconedaAESPI(AssociaçãodeEnsinoSuperiordoPiauí)eobservamosqueos

gráficosestatísticosdetamanhoeintervaloentreasmensagenssãoautosimilaresemrelação

ao tempo,ou seja,o gráficode tamanhoe intervalo entremensagensobtidocom a análise

doslogs relativos a um dia de utilizaçãodo servidorsãosemelhantesaosgráficosobtidos

atravésdaanálisedo log completodetrêsmeses.

5.3Resultadose análise 46

A partir dessaanáliseinicial resolvemosexecutarnossosexperimentossubmetendonos-

so servidorde testesa duascargas,uma delasobtida a partir dos logs do servidoranji-

nho.dsc.ufpb.br, a segundasendoumacarga sintética. A primeiracarga foi obtidaa partir

do log relativo a um dia quefossebastantesemelhanteà cargamédiado período,a segunda

cargafoi simuladadeformaa testarasaturaçãodeutilizaçãodosistemadecorreioeletrôni-

co,mandandorajadasdemensagensemtamanhosvariadosparaverificara vazãosuportada

peloservidor.

As mediçõesde performanceforam feitassobo pontode vista do cliente. Medimoso

tempoqueo servidorgastaparaprocessarcadamensagemsobo pontode vista do cliente

remotoquea estáenviando,analisando,assim,o impactoreal no desempenhodessesser-

viçosdecorreioeletrônicoobservadopelosusuáriosquandoseusamasdiversasformasde

armazenamentoestável.

5.3 Resultadose análise

Nestaseçãoapresentaremosdiversosgráficose tabelasmostrandotodososresultadosobti-

dosnosexperimentossintéticosebaseadosnoservidordecorreioeletrônico,bemcomouma

análisedessesresultados.

5.3.1 Resultadosdosexperimentossintéticos

Inicialmenteapresentaremososresultadosindividuaisparacadaumdossistemasdearquivo

testadosparaverificar a influênciados fatorestamanhodo arquivo, tamanhodo registro

utilizadoe existênciaou nãode concorrência.Em seguidaapresentaremosalgunsgráficos

comparandoosresultadosobtidospelossistemasdearquivo avaliados.

Resultadospara o sistemade arquivosExt2:

O sistemade arquivos Ext2 atingeumavazãomáximade cercade 1.5Mbytes/segundo

nasoperaçõesde gravaçãode dados,parablocosde até32Kbytes,devido à alta sobrecar-


200

400

600

800

1000

1200

1400

1600

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

Tamanhodecadaregistro(KBytes)

Arquivo de32KbytesArquivo de320Kbytes


Figura5.1: Desempenhodo sistemaExt2emgravaçõessíncronassemconcorrência




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

550

500

450

400

350

300

250

200

150

Figura5.2: DesempenhodosistemaExt2emgravaçõessíncronascomconcorrência

ga impostaao discoparasegravar os meta-dadosa cadaoperação,uma vez queos blo-

cosda dadosnecessáriosparaarmazenaros mesmossãoalocadosem tempode execução

e essaoperaçãoexige gravaçãosíncronaem disco, issopodeserobservadona figura 5.1.


0

500

1000

1500

2000

2500

3000

3500

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)




Figura5.3: Desempenhodo sistemaExt2emregravaçõessíncronassemconcorrência




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

1800

1600

1400

1200

1000

800

600

400

200

Figura5.4: DesempenhodosistemaExt2emregravaçõessíncronascomconcorrência

Nasoperaçõesde regravaçãode dados( figura 5.3 ), com blocospreviamentealocados,o

sistemaExt2 conseguemelhorarsuaperformanceematé100%atingindoumavazãomáxi-

made3Mbytes/segundo.Mesmonessecaso,aindaexistesobrecargaemcadaoperaçãode


gravaçãodevido à necessidadede segravar informaçõescomoo offsetdo arquivo no nó-i

correspondente,alémdosdadosemsí.

A existênciadeconcorrênciapelousodo discoafetaconsideravelmentea performance

do sistemaExt2, principalmentenasoperaçõesde gravaçãode dados. Nessecaso,como

pode ser visto na figura 5.2, a vazãonão consegue ultrapassar500Kbytes/segundo. O

desempenhodessesistemasofreu, também,uma considerável quedana performancedas

regravaçõeschegandoaum pico1.6Mbytes/segundo,observeafigura5.4.

Resultadospara o sistemade arquivosReiser:




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

700

600

500

400

300

200

100

0

Figura5.5: DesempenhodosistemaReiserFSemgravaçõessíncronassemconcorrência

Nasoperaçõesdegravaçãolivresdeconcorrência,figura5.5,o desempenhodosistemaé

bastantelimitadopelotamanhodoregistroutilizado,queprovocamaissobrecargaaosistema

operacionalpelomaiornúmerodeoperações.Nagravaçãodearquivospequenos(32Kbytes)

o sistemaReiserFShavia apresentado,inicialmente,umresultadomuitosuperioremrelação

aodesempenhodosistemaExt2eemrelaçãoaoseupróprioresultadoparaoutrostamanhos

de arquivo. Imaginou-seque isso sedevia a uma melhor performancedessesistemanas





Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

130120110100908070605040

Figura5.6: Desempenhodo sistemaReiserFSemgravaçõessíncronascomconcorrência




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

10000900080007000600050004000300020001000

0

Figura5.7: DesempenhodosistemaReiserFSemregravaçõessíncronassemconcorrência

operaçõessobrearquivospequenos,queé um dosobjetivosdo projetodo ReiserFS.Apóso

resultadodasexecuçõescompletasdostestesverificamosqueessadiferençaeraprovocada

porumusoeficientedacacheexistentenodiscoporpartedessesistemanessasoperações(o





Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

18001600140012001000800600400200

0

Figura5.8: DesempenhodosistemaReiseremregravaçõessíncronascomconcorrência

sistemaExt2tambémteveumganhonasoperaçõesdegravaçãosobrearquivosde32Kbytes).

De um modo geral, o sistemaReiserFSteve um desempenhoinferior àqueleobtido pelo

sistemaExt2nasoperaçõesdegravaçãolivresdeconcorrência.

Ao analizarosresultadosobtidosporessesistemadearquivosnasoperaçõesderegrava-

ção,Figura5.7, podemosobservar duascoisasinteressantes:i) a performancenagravação

dosarquivosde32Kbytesfoi extremamentealtaemalgumasinstânciasdeexperimentos,até

ultrapassandoavazãomáximadodisco,chegandoavaloresdequase30Mbytes/s,o quenos

levou a executarnovos testesquemostraramqueissoeraresultadoda utilizaçãoda cache

existenteno disco (512Kbytes);e ii) Quantomaior o registro, bemmelhorseráa perfor-

mancederegravaçãonessesistema.Issosedeve aofatodequeaosepré-alocarblocosno

reiserFS,estefazusodegrandesblocosnãoformatados4, permitindoqueo discoatinjasua

máximavazão.O desempenhodessesistemanasregravaçõeslivresdeconcorrênciachegou

asertrêsvezessuperioràqueleobtidopelosistemaExt2.

Ao seadicionarconcorrênciaao usodo discoo sistemaReiserFSsofreumaperdade

desempenhosemelhanteàquelasofridapelosistemaExt2, mantendoumaperformanceno-

vamenteinferior nasoperaçõesde gravação,figura 5.6. Nas operaçõesde regravaçãoo4semelhantesaosExtentsusadosemoutrossistemasdearquivosUNIX


impactoémaiorqueaqueleobservadonoExt2,levandoo desempenhoaseequipararàquele

obtidopeloprimeirosistemadearquivos,observe a figura5.8. Aparentemente,a adiçãode

concorrênciano usodo discolimitou a performancedo ReiserFSa um patamarde1.7Mby-

tes/segundo,desdequenãoexistaoutrotipo desobrecarganasoperações,issolevouo siste-

maa seequipararaoEXT2 naregravaçãodedados,casoondeerabastantesuperiorsema

existênciadeconcorrência.

Resultadospara o sistemade arquivosSalius:

4000

5000

6000

7000

8000

9000

10000

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)




Figura5.9: DesempenhodosistemaSaliusemgravaçõessíncronassemconcorrência

O sistemade arquivos Saliustem um comportamentobemmaisestável queos demais

sistemas.Issoserefletena menorvariânciaencontradanasdiversasinstânciasdo mesmo

testeque eramexecutadasparasechegar a um resultadomédio. Como essesistemafaz

todasas operaçõessobredadose meta-dadosrelativas às chamadasde sistemawrite de

formaassíncrona,o fatorlimitanteparaaperformancedomesmopassaaseravazãodarede

easobrecargaimpostapelotamanhodosregistrosutilizados.


1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)




Figura5.10:DesempenhodosistemaSaliusemgravaçõessíncronascomconcorrência

4000

5000

6000

7000

8000

9000

10000

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)




Figura5.11:DesempenhodosistemaSaliusemregravaçõessíncronassemconcorrência

Comojá eraesperado,devido aosresultadospréviosencontradosemnossotrabalhoan-

terior com essesistema[BCPS02], as operaçõesde gravaçãoe regravaçãode dadostêm

desempenhoextremamentesemelhante( figuras5.9e5.11), já queapréalocaçãodeblocos

nãotêm influênciasobreumaoperaçãoquevai serrealizadasemo usosíncronodo disco.


1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)




Figura5.12:Desempenhodo sistemaSaliusemregravaçõessíncronascomconcorrência

Emtodosostesteslivresdeconcorrência( figuras5.9e5.11), o principalfatorlimitantede

performancefoi a sobrecargaimpostapelotamanhodo registro. A vazãomáximachegoua

poucomenosque10Mbytes/segundo,o quecorrespondea 80% da vazãomáximade uma

redeFastEthernet.

A concorrênciaprovocadapelacargaimpostaatravésdeNFSdegradouconsideravelmen-

teo desempenhoemtodasasoperaçõesdosistemasalius,masessadegradaçãofoi inferior à

observadanosexperimentoscomosoutrossistemasdearquivo. A vazãomáximacaiucerca

de50%atingindoum pico depoucomenosque5Mbytes/segundo,issopodeserconstatado

nasfiguras5.10e5.12.

Gráficos comparativosde desempenho:

Paracompararo desempenhodostrêssistemascriamosgráficosquemostrama vazão

obtida por estesseparadospor tamanhode arquivo, existênciade concorrênciae tipo de

operação(gravaçãoou regravação). Incluímosapenasos resultadosparadois tamanhosde

arquivos,32Kbytese 32000Kbytespor seremestesosquetrouxeraminformaçõesmaissig-

nificativas.


Gráficos comparandoa performancedegravação

EXT2FSSaliusFSReiserFS


Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

10000900080007000600050004000300020001000

0

Figura5.13:Desempenhocomparativo paragravaçõessíncronasdeumarquivo de32Kbytes

semconcorrência

Podemosobservar nessesgráficosqueo sistemadearquivossaliusobteveum desempe-

nhobastantesuperioraosdemaisnasoperaçõesdegravaçãodedados,principalmentequan-

do existia a presençadeforte concorrênciapelousodo discoquandoessesistemachegoua

ser9 vezesmaiságil queosdemais( figuras5.14e5.16). Semaexistênciadeconcorrência

o sistemaSaliuschegouaserde3 a6 vezesmaisrápido,dependendodotamanhodoarquivo

sendogravado( figuras5.13e5.15).

Gráficos comparandoa performancederegravação




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

500045004000350030002500200015001000500

0

Figura5.14:Desempenhocomparativo paragravaçõessíncronasdeumarquivo de32Kbytes

comconcorrência

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)


ReiserFS SaliusFS EXT2FS

Figura 5.15: Desempenhocomparativo para gravaçõessíncronasde um arquivo de

32000Kbytessemconcorrência

Nos experimentoscom regravaçãode dadostemosum quadrobastantediferente,onde

o sistemade arquivos Reiserchega a rivalizar o sistemaSaliusna performancede regra-




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

500045004000350030002500200015001000500

0

Figura 5.16: Desempenhocomparativo para gravaçõessíncronasde um arquivo de

32000Kbytescomconcorrência



Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

10000900080007000600050004000300020001000

0

Figura5.17:Desempenhocomparativo pararegravaçõessíncronasdeumarquivo de32Kby-

tessemconcorrência




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

5500500045004000350030002500200015001000500

0

Figura5.18:Desempenhocomparativo pararegravaçõessíncronasdeumarquivo de32Kby-

tescomconcorrência

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

1 10 100

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)


ReiserFS SaliusFS EXT2FS

Figura 5.19: Desempenhocomparativo para regravaçõessíncronasde um arquivo de

32000Kbytessemconcorrência

vaçãode arquivos grandesquandonãoexistia concorrência,figura 5.19. O sistemaExt2

apresentouum desempenhobeminferior aosdemaisnessesexperimentosderegravação.A




Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

100101

500045004000350030002500200015001000500

0

Figura 5.20: Desempenhocomparativo para regravaçõessíncronasde um arquivo de

32000Kbytescomconcorrência

performancedo sistemaSaliusfoi cercade 3 vezessuperioraosdemaissistemasquando

havia concorrênciapelousododisco( figuras5.18e5.20).

Nestaprimeirapartedessesresultadospodemosverqueo tamanhodo arquivo tevepou-

cainfluênciano desempenhodo sistemadearquivo Saliustantoparagravaçõesquantopara

regravaçõesemarquivoscomblocospré-alocados.Essefatojá havia sidoobservadoemum

trabalhoanterior[BCPS02]. O desempenhonagravaçãoeregravaçãonosistemadearquivos

Reisertambémnãoé muito afetadopelo tamanhodo arquivo utilizadoparatestecomuma

exceção. Em algunstestesrealizadosutilizandoo menortamanhode arquivo (32Kbytes)

essesistemaapresentouum desempenhoexcepcionalmentealto, inclusive ultrapassandoa

vazãomáximado discoemutilização.Issoaconteceuporqueessesistemafazum usoefici-

entedamemóriacacheexistentenodisco(512Kbytes),sendoestasuficienteparaagruparas

operaçõessobredadose meta-dadosemumapequenagravaçãodeum arquivo. O resultado

do testefoi obtidoatravésdamédiada vazãoobtidaem 10 instânciasdo experimento,en-

tretanto,cadainstânciaerarealizadaapósumarecriaçãodo sistemadearquivos,atravésdo


comandomkreiserfs, o queexplica o usoeficientedacachedo disco.Ao serepetirosexpe-

rimentos,aumentandoo númerodeinstânciaspara50,edeixando-sederecriaro sistemade

arquivosantesdecadauma,osresultadosatingiramosvaloresesperados,queforamusados

nosgráficos.

O tamanhodo registro utilizado em cadaoperaçãode gravaçãomostrouter bemmais

influênciaqueo tamanhodo arquivo nosresultadosdosexperimentos.Podem-sefazerduas

observaçõesimportantesatravésdessesresultados:i) A existênciadeconcorrênciapelouso

dodiscodeteriorabastanteo desempenhodossistemasdearquivoquefazemusodegravação

síncronaparaestabilizarosdados( compareafigura5.15comafigura5.16), e ii) O sistema

dearquivosExt2apresentaumdesempenhobeminferior aosdemaissistemasnasoperações

deregravaçãodeumarquivo comblocospré-alocados( figuras5.17a 5.20).

A influênciadaconcorrênciapelousodo discofoi um poucomaiorquea esperada,en-

quantoa,relativamentepequena,influênciado tráfegogeradonaredesobreo sistemaSalius

já eraesperadapelosresultadosobtidosemoutrotrabalhodecomparação[BCPS02]. A per-

da de desempenhodo sistemaSaliusfoi maior quea dessetrabalhocitado,provavelmente

porquenestesnovosexperimentosacargageradapelocompartilhamentodedadosatravésde

NFSébemmaiorqueacargasimuladautilizadanosexperimentosprévios,ondeutilizamos

umaferramentasintéticaparasaturararede.O resultadoruim naregravaçãodedadosobtido

pelosistemadearquivosExt2 emrelaçãoaosistemaReiserFS,vejafigura5.19,éexplicado

pelo fato desseúltimo fazerusode extents5, aproximando-sedosresultadosobtidospelo

sistemadearquivosSalius.

Segueum sumáriodasobservaçõesfeitasatravésda análisedosresultadosdosexperi-

mentossintéticos:

� A concorrênciapelousodo discopodevir a prejudicarasoperaçõesestáveisnossis-

temasbaseadosemgravaçãosíncronaaopontodeinviabilizarasuautilização;

� A existênciadetráfegoemumaredeethernetprejudicouo desempenhodosistemaSa-

lius, entretantoesseprejuízofoi menorquandocomparadoàquelesofridopelosoutros

sistemascomaconcorrênciapelousodo disco;

5Grandesblocosnãoformatadosque,sepreviamentealocados,permitemumamaiorvazãopor seremcon-

tíguos.


5.3.2 Resultadosdosexperimentoscomum servidor SMTP

A análisedos dadosobtidosatravés do monitoramentodo servidorde correio eletrônico

anjinho.dsc.ufpb.br no períodocitadoanteriormentenosmostrouosseguintesresultados:

� 2.6Gbytesé o total dedadosqueforamrecebidospeloservidor;

� 14Kbyteséo tamanhomédiodasmensagens;

� 9.8Mbyteséo tamanhodamaiormensagem;

� 202bytesé o tamanhodamenormensagem;

� Houvepoucavariâncianessetamanho6.

Baseando-senessesdados,escolhemosum dia queapresentasseum perfil de carga se-

melhanteaesse.O diaescolhidoparatersuacargasubmetidaaonossoservidordetestesfoi

5 demarçode2002queapresentouo seguinteperfil demensagens:

� 83.3Mbyteséo total dedadosqueforamrecebidospeloservidor;

� 12.4Kbyteséo tamanhomédiodasmensagens;

� 2.6Mbyteséo tamanhodamaiormensagem;

� 227bytesé o tamanhodamenormensagem;

� Houvepoucavariâncianessetamanho7.

O testeconsistiuemseverificaro tempoqueo servidordecorreioeletrônicodemorava

paraprocessaro recebimento8 dototaldemensagensrelativasaessedia. Paratanto,paraca-

damensagemobtidado log dodia5 demarçoeraenviadauma,deigual tamanhoaoservidor

deteste.O resultadoconsistedotempogastopeloservidorpararecebertodasasmensagens.6A grandemaioriadasmensagens(9̃0%)eradetamanhoentre10 e 16 Kbytes7A grandemaioriadasmensagens(9̃2%)eradetamanhoentre10 e 16 Kbytes8Ao receberumamensagem,o servidora armazenadeformaestável nafila paraserprocessadaposterior-

mente.


Parasetestarum novo sistemadearquivos,apartiçãodo discorígido erarecriadaeo servi-

dordecorreioeletrônicoerareimplantadosobreessapartição.Osresultadosobtidosatravés

damédiadetrêsinstânciasdetesteparacadasistemadearquivosfoi o seguinte:

Sistemadearquivos Salius Ext2 ReiserFS

Tempogasto(segundos) 302.3 374.6 646.8

O resultadodessetestenostrouxe algumassurpresase por essemotivo resolvemoses-

tenderos testessobreo servidorde correioeletrônicoparaverificar o comportamentodo

mesmosobcargasdiversificadas.

Paraostestessimuladosresolvemostestardiversostamanhosdemensagenseverificara

influênciado númerodeseçõessimultâneas9 sobreo desempenho,imaginandoqueossis-

temasdearquivo tradicionaisapresentemumamelhorano seudesempenhocomo aumento

donúmerodeseçõesparalelas,principalmentecommensagenspequenas.Cadainstânciado

testeconsistia-sedo envio de500mensagensdetamanhofixo parao servidorvariando-seo

númerodeseçõessimultâneasentre5, 10e20emedindo-seo tempogastoparacompletaro

envio dessas500mensagens.Foramtestadasmensagensdetamanhos1, 10,100e1000Kby-

tes.Osresultadosobtidos, separando-ospor sistemadearquivo testado,foramosseguintes

( resultadosemsegundosporgrupode500mensagens):

SistemadearquivosSalius:Númerodeseções 1Kbyte 10Kbytes 100Kbytes 1000Kbytes

5 12.19 13.51 35.61 152.81

10 8.78 9.29 30.88 145.74

20 6.54 7.09 28.29 142.27

SistemadearquivosExt2:9Cadaseçãosimultâneaé equivalentea um programaclientedeusuárioconectadoao servidordecorreio

eletrônico


Númerodeseções 1Kbyte 10Kbytes 100Kbytes 1000Kbytes

5 17.97 18.73 42.15 168.67

10 11.47 12.43 35.36 150.33

20 8.84 9.21 33.92 146.20

SistemadearquivosReiser:Númerodeseções 1Kbyte 10Kbytes 100Kbytes 1000Kbytes

5 29.57 33.82 53.62 203.85

10 27.00 31.43 49.99 197.89

20 24.39 28.82 46.85 193.78

Parasimplificaro entendimento,criamosgráficosbaseadosnessesresultadosmostrando

a vazãoobtida pelo servidorsobrecadaum dos sistemasde arquivo. Os gráficosestão

separadospelonúmerodeseçõese mostrama vazãoatingidapelossistemasvariando-seo

tamanhodecadamensagem.

0

5000

10000

15000

20000

25000

30000

35000

1 10 100 1000

Vaz

ãoob

tida

(Byt

es/s

egun

do)

Tamanhodecadamensagem(KBytes)

qmail sobreReiserFSqmail sobreEXT2

qmail sobreSalius

Figura5.21:Desempenhocomparativo doservidordecorreioeletrônicocom5 seçõesaber-

tassimultaneamente


0

5000

10000

15000

20000

25000

30000

35000

1 10 100 1000

Vaz

ãoob

tida

(Byt

es/s

egun

do)



qmail sobreSalius

Figura 5.22: Desempenhocomparativo do servidorde correio eletrônicocom 10 seções

abertassimultaneamente

0

5000

10000

15000

20000

25000

30000

35000

40000

1 10 100 1000

Vaz

ãoob

tida

(Byt

es/s

egun

do)



qmail sobreSalius

Figura 5.23: Desempenhocomparativo do servidorde correio eletrônicocom 20 seções

abertassimultaneamente


Comopode-seobservar, o sistemadearquivosSaliuslevaumaligeiravantagememtodos

ostestesemrelaçãoaosistemaExt2,enquantoo sistemaReiserFSapresentouumdesempe-

nhobastanteinferior aosoutrosdois,o quefoi umasurpresa,umavezqueessesistemafoi

projetadoparaapresentarvantagensemoperaçõessobrearquivospequenos,o queé o caso

damaioriadasinstânciasdosexperimentoscomo servidordecorreioeletrônico.A expli-

caçãoparaessefraco desempenhodo sistemade arquivosReiserFSpodeestarjustamente

nasuaprincipalcaracterística,o usodeárvoresbalanceadasparaestruturarosmeta-dados.

Issonosleva a umaformadelocalizaçãodearquivoscomdesempenhoconstante,sempior

ou melhorcaso,alémdisso,no casodesistemasdearquivo aindanãomuitoutilizados,com

poucosarquivoscriados,a árvoreprecisaserconstantementereestruturada,adicionando-se

novosbraçose um novo topo, levandoà criaçãode meta-dadosextrasnosnósinternosde

pesquisa,fatoquenãosetornanecessárionosoutrosdoissistemas.

É importantesalientarum detalhe,entretanto.Ao serealizarosexperimentoscommen-

sagensde 1Mbyte o sistemaSaliusmostrouuma limitação importante. Como as rajadas

de mensagenserammuito rápidas,os servidoresde replicaçãonãotinhamtemposuficien-

te paraliberara memóriaalocadaparaasprimeirascópiasrecebidas,tendosuacapacidade

esgotada,degradandobastanteo desempenhodo sistema.Issoocorreporqueosservidores

de replicaçãoesperam60 segundosantesde remover qualquerréplicada memóriavolátil,

aguardandoqueestastenhamsido estabilizadasno clientequeassolicitou. A soluçãofoi

aumentar, momentaneamente,acapacidadedememóriadasmáquinasondeosservidoresde

replicaçãoexecutavam para320Mbytes. Issosolucionouesseproblemaparaessavazão(

500Mbytesempoucomaisde2 minutos) masdeixouevidentequea vazão,a longoprazo,

do sistemaSaliusestálimitadapelaquantidadede memóriavolátil existentenasmáquinas

remotas.

ApósessaadaptaçãoeraesperadoummelhordesempenhodosistemaSaliusbaseando-se

nosresultadosdosexperimentossintéticos.Comoo sistemaReiserFSmostrou-sebastante

inferior aosdemaisnostestesanterioresquandosetratavadegravaçãodenovosdados,o seu

fracodesempenhojá eraesperado.A poucadiferençaentreo sistemaExt2eo sistemaSalius

foi umasurpresamasexplica-sepelo fatodequeo processodereceberumamensagemde

correioeletrônicoenvolve muito maisoperaçõesquegravar dadosem arquivos atravésda

chamadade sistemawrite. Operaçõesexclusivamentesobreos meta-dadosde um arquivo

5.4Conclusão 66

comomover, adicionarentradadediretório,entreoutrasaindasãorealizadasdeformasín-

cronanosistemadearquivosSalius.Aparentemente,o servidordecorreioeletrônicoqmailé

limitadomaisporessasoperaçõesquepor aquelasaceleradasnosistemaSalius,comowrite

e fsync.

5.4 Conclusão

Nestecapítulodescrevemosumasériede experimentosrealizadoscom astrês implemen-

taçõesde sistemasde arquivo com suporteà gravaçãoestável de dadosescolhidos.Os re-

sultadosdestesexperimentosforamapresentadose analisadoscomo objetivo desechegar

a algumasconclusõessobreasvantagense desvantagensdessastrêsabordagensutilizadas

paraseestabilizardados.Uma partedosresultadoscorrespondeuàsespectativasbaseadas

no projetodessessistemasde arquivo. Alguns resultados,entretanto,trouxeramalgumas

surpresascomoa poucavantagemdo sistemaSaliussobreo Ext2 nostestescomo servidor

decorreioeletrônico.

A partir dosresultadosobtidosdessesexperimentos,chegamosàsseguintesconclusões

práticassobregravaçãoestável dedadosemum contexto geral:

� A utilizaçãodememóriaremotacomoalternativaparaagravaçãosíncronadedadosé

viável empraticamentetodasassituações;

� Extensões10 sãoumaboaalternativa paraaplicaçõesquetrabalhemcomgravaçãode

grandesarquivos.

As seguintesconclusõesforamfeitasnocontexto deservidoresdecorreioeletrônico:

� Processarmensagensdecorreioeletrônicoé umatarefa limitadapor operaçõessobre

meta-dadosmaisquepor operaçõesde gravaçãode dados,portantoobtém-sepouca

vantagemaoseutilizar um sistemaqueusamemóriaremotaparaestabilizardados;

� A implementaçãodeárvoresB utilizada,ReiserFSversão3, nãosemostrouumaal-

ternativaviável emrelaçãoaosnós-inessecontexto.

10Grandesblocoscontíguosnãoformatados,nãoobrigatoriamenteemconjuntocomárvoresB.

Capítulo 6

Conclusão

Nestecapítulofinal dadissertação,iremosfazerum sumáriodosobjetivosqueforamtraça-

dosao longodo seudesenvolvimentoe umaanálisecomparativa entreestesobjetivose os

resultadosapresentados.Além disso,iremosapresentarumacronologiadostrabalhosepro-

jetosqueserviramdebaseparaestadissertação.Porúltimo, faremosalgumasconsiderações

finaissobreo programademestrado.

O objetivogeraldestetrabalhofoi elucidarasprincipaisquestõesquesurgemnamentede

administradoresdesistemasaosedepararcomumaaplicaçãoquefazusodearmazenamento

estáveldedados.Paratantoo trabalhoenvolveuduaslinhasdepesquisa:i) tolerânciaafalhas

e ii) análisede desempenho.Fizemosumaabordagemligadaà áreade tolerânciaa falhas

no Capítulos2, em queforam mostradosos principaisproblemasexistentesna criaçãode

serviçosde armazenamentoestável de dadose algumassoluções,e no Capítulo4, emque

foramdetalhadasasimplementaçõesdetrêssistemasdearquivo enfocandoa semânticade

gravaçãoestável dedados.

Maisespecificamente,procuramosentendero problemadoarmazenamentoestável, ana-

lisaralgumasimplementaçõesutilizadasecriarumaimplementaçãoalternativaàsexistentes.

Ao estudaravaliaçãodedesempenhodesistemasdearmazenamento,nossosobjetivoseram

entenderasvariáveisexistentesesuainfluêncianesseâmbito.

O ponto de partida para o desenvolvimento destetrabalho foi o projeto de imple-

mentaçãode um sistemade arquivos baseadona replicaçãoremota de buffers [Sta;

BCPS02]. Essesistemade arquivos havia sido idealizadoem um outro trabalhode dis-

sertaçãomassuaimplementaçãonãopodeserfeita naquelemomento.O desenvolvimento

67

68

dessesistemadearquivosduroucercadeseismeses,tendosidoiniciadonocomeçode2001.

Ao longodesseprocesso,o projetofoi alteradoparamelhorseadequaràstecnologiasusadas

no seudesenvolvimento.Nessemomento,aosefazeremavaliaçõespreliminaresdedesem-

penhoparaa publicaçãodeartigos,surgiu a ideiadedesenvolverumestudodeavaliaçãode

desempenhodeserviçosdearmazenamentoestável dedados,incluindoo nossosistemade

arquivos.

A partirdosegundosemestrede2001o sistemadearquivosSalius[BCPS02] estavasen-

do comparadocom o sistemaquefoi a basede seudesenvolvimento,o Ext2, e decidimos

queesseseriao nossoobjetodeestudo:Avaliar sistemasdearquivo no âmbitodearmaze-

namentoestável dedados.Passamosentãoa recolherbibliografiaparaestudodessaáreajá

pensandono desenvolvimentodadissertação.

Nesseperíodofoi verificadoqueavaliaçãodedesempenhodessetipo desistemaé uma

tarefa complexa e queestáfortementeacopladaaotipo deaplicaçãoquevai utilizá-lo. Ou-

tra observaçãoquepôdeserfeita foi que,apesardeexistiremmuitostrabalhosimportantes

sobremetodologiasde avaliação,existia umacarênciade publicaçõescientíficastrazendo

comparaçõesfeitasentresistemasdearquivo usandotaismetodologias.As publicaçõesexis-

tentessempreprocuravammostrarasvantagensdealgumprojetodesenvolvido peloautore

limitando-seaumpequenonúmerodeexperimentos.

Nessemomentotínhamosa ambiçãode criar umaespéciede tratadofinal sobresiste-

masdearmazenamentoestável dedados,o queeraclaramenteimpossível deseralcançado

no âmbitodo programade mestrado,visto que teria queenvolver muitosoutrossistemas

dearquivo, muito maisestudosobreoutrasalternativasdegravação,semfalarnaevolução

constantequeessastecnologiassofremcom o passardosanos. Por fim, resolvemoslimi-

tar o nossoestudoa técnicasde criaçãode serviçosde armazenamentoestável, algumas

implementaçõesimportantesde sistemasde arquivo quepudessemseravaliadasno nosso

ambientee restringirosexperimentosadoiscontextos: i) algumasavaliaçõessintéticaspara

trazerumaidéiasobreo comportamentodessessistemasdearquivo, e ii) umaavaliaçãode

desempenhodeumaaplicaçãodeproduçãoqueutilize armazenamentoestável.

A escolhadeum servidordecorreioeletrônicocomoa aplicaçãoa serusadacomofer-

ramentadeavaliaçãomostrou-seumadecisãoacertadaporque,longedemostrarresultados

extremamentefavoráveisa nossaimplementaçãodeum sistemadearquivos,o quefoi mos-

69

tradonosexperimentossintéticos,o queseviu foi quealimitaçãodeperformanceprovocada

pelosdiscosnessetipo deaplicaçãonãoestáligadaasoperaçõesdegravaçãodedadosem

si, e sim às operaçõesexclusivamentesobremeta-dados.Para nós isso foi uma surpresa

inesperadae trouxemaisàevidênciatrabalhosquejá exploramessalacuna[GP94].

Quantoaosobjetivospropostosnaintroduçãodo trabalhoacreditamosqueosresultados

obtidose asconclusõesextraídasdosmesmostrazemumaboaquantidadede informação

paraaquelesinteressadosementenderumpoucomaissobresistemasdearmazenamentoes-

tável dedadoseprocuramumafonteinicial deinformaçãosobreaavaliaçãodedesempenho

dessetipo desistema.Dessaforma,consideramosqueestetrabalhoébastanteútil econclui

umprocessoquefoi iniciadoaalgunsanoscomacriaçãodoprojetoSalius[Sta].

Fazendoum resumoabstratodasconclusõestiradasdestetrabalho,podemosdizerque,

a forma de implementaçãoutilizada no sistemade arquivo tem uma grandeimportância

sobrea performancedo mesmoem armazenamentoestável, basta,paratanto, observar a

grandediferençade performanceem regravaçõesobservadanostrêssistemasdependendo

do contexto. Duasidéiasjá consagradasconfirmaramsuaforça,replicaçãoremotadedados

e usode grandesblocos(extents) paragravaçãodo conteúdode arquivos. Pelomenosno

contexto de nossosexperimentoscom servidoresde correioeletrônico,o usode árvoresB

nãodemonstrouserumaboaalternativaparagravaçãoestável dedados.

Para finalizar, gostaríamosde acrescentarque estetrabalhode dissertaçãotrouxe-nos

motivaçãoespecialpor dois motivos: i) semprefoi nossointeresseo desenvolvimentode

software básicoe esseprojetofoi a primeiraoportunidadedetrabalharcomo códigofonte

de um sistemaoperacional,e ii) foi um trabalhoqueenvolveuduasáreasdistintasde pes-

quisa,tolerânciaa falhase avaliaçãodedesempenho.A primeiramotivaçãofoi plenamente

satisfeitapoistivemosqueestudaraestruturainternadosistemaoperacionalnaprática.Isso

semostrouútil nosmomentos,na implementação,em quealgumacoisanãofuncionava e

precisávamosdepuraroserros.Comosefazparadepuraro núcleodeum sistemaoperacio-

nal?Conhecimentosobreaestruturainternadocódigoajudoubastantenesseponto.Sobrea

segundamotivaçãopodemosdizerquetrabalhosmultidiciplinares(nãoé exatamenteesteo

casomassãoáreasdepesquisadistintas)tendema trazerresultadosmaispráticoseesseera

umdosnossosobjetivos.

Consideramosqueo trabalhodesenvolvido contribuiu daformaesperadaparaaquelesin-

70

teressadosnoestudodestaáreae tambémquefoi umdesafionecessáriodentrodoprograma

demestrado.

Bibliografia

[BCPS02] FranciscoV. Brasileiro,WalfredoCirne, Erick Passos,andTatianaS. Stanchi.

Using remotememoryto stabilizedataefficiently on anext2 linux file system.

In XX SimpósioBrasileiro deRedesdeComputadores, 2002.

[Bra] T. Bray. Bonnie benchmark source code, 1990.

ftp://www.cs.umbc.edu/pub/elm/iobenchmarks/bonnie.sh.

[CLG� 94] PeterM. Chen,EdwardK. Lee,GarthA. Gibson,RandyH. Katz,andDavid A.

Patterson.RAID: High-performance,reliablesecondarystorage.ACM Compu-

ting Surveys, 26(2):145–185,1994.

[CNC� 96] PeterM. Chen,WeeTeckNg, SubhachandraChandra,ChristopherAycock,Gu-

rushankarRajamani,andDavid Lowell. Therio file cache:Surviving operating

systemcrashes.In Architectural Supportfor ProgrammingLanguagesandOpe-

ratingSystems, pages74–83,1996.

[CP93a] P. M. Chen and D. A. Patterson. A new approachto I/O performance

evaluation—self-scalingI/O benchmarks,predictedI/O performence.In Pro-

ceedingsof the1993ACM SIGMETRICSConferenceon MeasurementandMo-

delingof ComputerSystems, pages1–12,SantaClara,CA, USA, 10–141993.

[CP93b] PeterM. ChenandDavid A.. Patterson.Storageperformance—metricsandben-

chmarks.In Proceedingsof theIEEE,81(8):1151–1165,August1993., 1993.

[CTT94] R. Card,T. Ts’o, andS. Tweedie. Designand implementationof the second

extendedfilesystem.In Proceedingsof theFirstDutch InternationalSymposium

on Linux, december1994.

71

BIBLIOGRAFIA 72

[ext] Linux ext3 file system development homepage.

http://beta.redhat.com/index.cgi?action=ext3.

[GP94] G. R. GangerandY. N. Patt. Metadataupdateperformancein file systems.In

Proceedingsof theUSENIX1994SymposiumonOperatingSystemsDesignand

Implementation, pages49–60,Monterey, CA, USA, 14–171994.

[jfs] Ibm jfs journaled file system homepage. http://www-

124.ibm.com/developerworks/oss/jfs/.

[LGG� 91] BarbaraLiskov, SanjayGhemawat,RobertGruber, Paul Johnson,Liuba Shrira,

andMichaelWilliams. Replicationin the Harp file system. In Proceedingsof

13thACM Symposiumon Operating SystemsPrinciples, pages226–38.Associ-

ationfor ComputingMachinerySIGOPS,1991.

[MG99] MarshallKirk McKusickandGregoryR. Ganger. Softupdates:A techniquefor

eliminatingmostsynchronouswritesin thefastfilesystem.pages1–17,1999.

[Mil96] EthanL. Miller. Towardsscalablebenchmarksfor massstoragesystems.In Fifth

NASAGoddard SpaceFlight CenterConferenceon MassStorage Systemsand

Technologies, pages515–528,sep1996.

[MJLF84] M. McKusick,W. Joy, S. Leffler, andR. Fabry. A fastfile systemfor unix. In

Proceedingsof theACM Transactionson ComputerSystems, august1984.

[MK] L. W. McVoy andS.R. Kleiman. Extent-likeperformancefrom a unix file sys-

tem.

[MS96] Larry W. McVoy and Carl Staelin. lmbench: Portabletools for performance

analysis.In USENIXAnnualTechnicalConference, pages279–294,1996.

[Nor] W. Norcott. Iozone benchmark source code, version 2.01.

ftp://www.cs.umbc.edu/pub/elm/iobenchmarks/iozone01.

[Org] IEEE Standards Organization. Ieee posix certifcation authority.

http://standards.ieee.org/regauth/posix/.

BIBLIOGRAFIA 73

[Pan94] PankajJalote.Fault Tolerancein DistributedSystems. PrenticeHall ,Inc, New

York, NY, 1994.

[PB90] A. PArk and J. C. Becker. Iostone: A syntheticfile systembenchmark. In

ComputerArchitectureNews18(2), pages45–52,1990.

[Rei] Hans Reiser. Reiserfs v.3 whitepaper.

http://www.namesys.com/content_table.html.

[RO92] MendelRosenblumandJohnK. Ousterhout.Thedesignandimplementationof

a log-structuredfile system.ACM TransactionsonComputerSystems, 10(1):26–

52,1992.

[RT74] DennisW. RitchieandKenThompson.TheUNIX time-sharingsystem.Com-

municationsof theACM, 17(7):365–375,July1974.

[SFGM93] Michael Stonebraker, Jim Frew, Kenn Gardels,and Jeff Meredith. The SE-

QUOIA 2000storagebenchmark.pages2–11,1993.

[Sta] TatianaSimasStanchi.Serviçodearmazenamentoestável comrecuperaçãopra

frentebaseadana replicaçãoremotade buffers. DissertaçãoCOPIN,Campina

Grande,fevereirode2000.

[Tan87] Andrew S. Tanenbaum.MINIX: A UNIX clonewith sourcecodefor the IBM

PC. theUSENIXAssociationnewsletter, 12(2):3–9,March1987.

[xfs] Sgi’s xfs homepage.http://www.sgi.com/software/xfs/.

ApêndiceA

AnáliseEstatísticadosResultados

Semprequesefazexperimentosenvolvendomuitasvariáveis,é importanteisolá-losda in-

terferênciade variáveis externas,garantindoassim,a representatividadedosresultados.A

estatísticaé umaferramentaútil paraindicarqueesseobjetivo foi atingido.Nosnossosex-

perimentos,isolamos,o melhorpossível,o ambientedeexecuçãodostestesparaevitar essas

interferências.Nosexperimentosqueenvolviam concorrência,entretanto,interferênciaera

umadasvariáveissendotestadas.Nessegrupodeexperimentos,foi maisdifícil sechegara

umvalorrepresentativo daperformancedossistemasdearquivo. Essapequenaanálisesobre

osresultadostemo objetivo devalidaressarepresentatividade.

A.1 Objetivos

Vamoschamarcadapontoemum gráfico(pontoondeasvariáveissendotestadaseramfi-

xas)deexperimento. Parasechegara um valor representativo, livre deinterferências,eram

executadasn instânciasde cadaexperimento. Nossoobjetivo foi chegar a um valor, para

n, suficientementegrandeparaquea médiaencontradanaamostrafosserepresentativa em

relaçãoà médiadapopulaçãodetodasaspossíveisinstânciasdesseexperimento.

Paraverificarseo tamanhodenossaamostra(n) erasuficientementegrande,tomamoso

seudesviopadrão,� , e dividimospor � � , chamandoessevalor encontradode coeficiente

devariação,q. Quantomenorfor o valor deq, emrelaçãoà médiadapopulação(m), mais

próximosestamosde um valor representativo paraa mesma,atravésde nossaamostrade

médiaM. Comonãosabemoso valor de m, fizemosumaaproximaçãousandoo valor da

74

A.2Análise 75

médiadaamostra,M. Consideramossuficienteparanossosobjetivosque,paracadaamostra

deum experimento,o valor encontradoparaq fosseno máximo10%do valor damédiada

amostra,M.

A.2 Análise

Aqui podemserobservadososvalores,paratodososexperimentos,dasmédiasedocoefici-

entedevariação,q, alémdarelaçãopercentualentreessesdoisvalores.

Paracadasistemadearquivosforamfeitasduastabelas,umaagrupandoosexperimentos

livresdeconcorrência,e outratrazendoos resultadosdosexperimentoscomconcorrência.

Podeserobservadoque,o coeficientedevariaçãoé maisbaixonosexperimentoslivresde

concorrênciae em todosos experimentoscom o sistemade arquivos Salius. Apenasnos

experimentosenvolvendoconcorrência,paraossistemasdearquivosReisereEXT2, encon-

tramosamostrasondeo coeficientedevariação,q, ficapróximodonossolimite estabelecido

de10%.

Emseguida,mostraremosalgumasfigurasapresentandoosgráficoscomparativosdaevo-

luçãodosresultadosdostrêssistemasdearquivo paradoisexperimentos:um livre decon-

corrênciae umenvolvendoconcorrência.

A.2Análise 76

A.2.1 Sistemade arquivosEXT2

Acimaosresultadosparaosexperimentoslivresdeconcorrência.

Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)

32 2 980 20.38(2.08%) 863 27.27(3.16%)

32 4 1327 38.35(2.89%) 2805 84.71(3.02%)

32 8 1478 26.01(1.76%) 2980 72.71(2.44%)

32 16 1482 48.01(3.24%) 3008 56.24(1.87%)

32 32 1496 21.54(1.44%) 3015 39.19(1.30%)

320 2 373 10.89(2.92%) 401 17.28(4.31%)

320 4 383 4.28(1.12%) 2810 44.67(1.59%)

320 8 781 20.22(2.59%) 2840 81.22(2.86%)

320 16 1347 67.21(4.99%) 2975 68.12(2.29%)

320 32 1471 33.39(2.27%) 2976 50.88(1.71%)

3200 2 347 16.51(4.76%) 349 3.97(1.14%)

3200 4 349 6.80(1.95%) 2807 160.84(5.73%)

3200 8 678 10.44(1.54%) 2914 40.79(1.40%)

3200 16 1275 20.78(1.63%) 2958 79.86(2.70%)

3200 32 1475 26.99(1.83%) 2955 82.74(2.80%)

32000 2 346 13.90(4.02%) 348 7.76(2.23%)

32000 4 346 5.22(1.51%) 2805 46.56(1.66%)

32000 8 669 20.00(2.99%) 2941 32.05(1.09%)

32000 16 1253 14.91(1.19%) 2954 153.31(5.19%)

32000 32 1468 39.19(2.67%) 2953 95.08(3.22%)

A.2Análise 77

Resultadosparaosexperimentoscomconcorrência:


32 2 170 6.76(3.98%) 201 8.68(4.32%)

32 4 260 10.84(4.17%) 712 32.68(4.59%)

32 8 341 14.83(4.35%) 1232 59.87(4.86%)

32 16 443 20.06(4.53%) 1507 47.01(3.12%)

32 32 511 24.06(4.71%) 1604 51.80(3.23%)

320 2 173 8.45(4.89%) 204 7.99(3.92%)

320 4 265 8.13(3.07%) 710 47.00(6.62%)

320 8 340 11.08(3.26%) 1212 112.95(9.32%)

320 16 449 16.43(3.66%) 1496 47.87(3.20%)

320 32 510 17.74(3.48%) 1605 55.69(3.47%)

3200 2 172 9.09(5.29%) 205 7.66(3.74%)

3200 4 266 18.91(7.11%) 708 28.39(4.01%)

3200 8 343 30.62(8.93%) 1237 52.94(4.28%)

3200 16 446 13.69(3.07%) 1501 68.29(4.55%)

3200 32 516 16.77(3.25%) 1620 78.08(4.82%)

32000 2 174 5.96(3.43%) 202 6.24(3.09%)

32000 4 261 9.44(3.62%) 711 59.93(8.43%)

32000 8 346 13.14(3.80%) 1198 42.40(3.54%)

32000 16 448 17.83(3.98%) 1509 94.01(6.23%)

32000 32 516 21.46(4.16%) 1603 143.14(8.93%)

A.2Análise 78

A.2.2 Sistemade arquivosReiser

Resultadosparaosexperimentoslivresdeconcorrência:


32 2 200 7.18(3.59%) 358 24.95(6.97%)

32 4 224 12.70(5.67%) 3776 41.53(1.10%)

32 8 274 6.41(2.34%) 3845 203.40(5.29%)

32 16 430 23.39(5.44%) 3873 125.09(3.23%)

32 32 596 12.03(2.02%) 3872 102.99(2.66%)

320 2 101 2.24(2.22%) 370 7.69(2.08%)

320 4 147 2.48(1.69%) 3959 59.78(1.51%)

320 8 267 8.46(3.17%) 3959 254.56(6.43%)

320 16 408 5.58(1.37%) 3881 143.98(3.71%)

320 32 625 17.81(2.85%) 4894 150.24(3.07%)

3200 2 97 1.01(1.05%) 345 8.62(2.50%)

3200 4 137 3.46(2.53%) 5617 108.40(1.93%)

3200 8 190 8.20(4.32%) 7134 96.30(1.35%)

3200 16 234 5.14(2.20%) 7967 387.19(4.86%)

3200 32 270 11.07(4.10%) 7731 164.67(2.13%)

32000 2 94 1.76(1.88%) 343 9.98(2.91%)

32000 4 132 7.61(5.77%) 7032 164.54(2.34%)

32000 8 177 2.76(1.56%) 9364 165.74(1.77%)

32000 16 217 6.59(3.04%) 9463 113.55(1.20%)

32000 32 246 3.05(1.24%) 9383 307.76(3.28%)

A.2Análise 79



32 2 43 1.33(3.11%) 162 6.01(3.71%)

32 4 80 2.63(3.29%) 801 31.87(3.98%)

32 8 97 3.36(3.47%) 1355 57.58(4.25%)

32 16 115 4.19(3.65%) 1608 72.68(4.52%)

32 32 120 4.59(3.83%) 1712 82.00(4.79%)

320 2 46 1.84(4.02%) 206 6.30(3.06%)

320 4 82 3.44(4.20%) 800 44.00(5.50%)

320 8 98 4.29(4.38%) 1351 43.77(3.24%)

320 16 118 5.38(4.56%) 1601 95.09(5.94%)

320 32 122 5.78(4.74%) 1708 147.57(8.64%)

3200 2 43 2.11(4.92%) 189 5.91(3.13%)

3200 4 79 2.45(3.11%) 798 27.13(3.40%)

3200 8 101 3.59(3.56%) 1350 49.54(3.67%)

3200 16 120 4.76(3.97%) 1599 63.00(3.94%)

3200 32 126 4.77(3.79%) 1704 71.73(4.21%)

32000 2 43 2.40(5.60%) 187 8.37(4.48%)

32000 4 78 5.78(7.42%) 796 37.81(4.75%)

32000 8 98 9.05(9.24%) 1345 40.61(3.02%)

32000 16 111 3.44(3.10%) 1597 57.97(3.63%)

32000 32 120 3.93(3.28%) 1701 82.66(4.86%)

A.2Análise 80

A.2.3 Sistemade arquivosSalius

Resultadosparaosexperimentoslivresdeconcorrência:


32 2 5061 153.34(3.03%) 5122 89.63(1.75%)

32 4 7843 96.46(1.23%) 7842 91.75(1.17%)

32 8 9584 259.72(2.71%) 9592 294.47(3.07%)

32 16 9855 607.06(6.16%) 9862 343.19(3.48%)

32 32 9981 238.54(2.39%) 9970 272.18(2.73%)

320 2 5014 297.83(5.94%) 5038 108.82(2.16%)

320 4 7789 161.23(2.07%) 7801 124.03(1.59%)

320 8 9550 258.80(2.71%) 9561 97.52(1.02%)

320 16 9821 170.88(1.74%) 9802 440.10(4.49%)

320 32 9923 319.52(3.22%) 9892 311.59(3.15%)

3200 2 4979 70.70(1.42%) 5023 129.59(2.58%)

3200 4 7834 227.18(2.90%) 7845 156.90(2.00%)

3200 8 9491 104.40(1.10%) 9503 135.89(1.43%)

3200 16 9843 253.94(2.58%) 9831 554.46(5.64%)

3200 32 9903 476.33(4.81%) 9895 288.93(2.92%)

32000 2 4933 110.99(2.25%) 4892 146.27(2.99%)

32000 4 7754 355.90(4.59%) 7763 187.86(2.42%)

32000 8 9512 183.58(1.93%) 9501 175.76(1.85%)

32000 16 9781 133.99(1.37%) 9807 124.54(1.27%)

32000 32 9861 158.76(1.61%) 9903 402.06(4.06%)

A.3Gráficosdecomparação 81



32 2 1299 40.13(3.09%) 1358 18.19(1.34%)

32 4 3412 44.01(1.29%) 3420 96.78(2.83%)

32 8 4562 125.91(2.76%) 4381 99.01(2.26%)

32 16 4762 318.57(6.69%) 4821 81.47(1.69%)

32 32 4825 117.73(2.44%) 5024 56.26(1.12%)

320 2 1402 48.64(3.47%) 1387 76.14(5.49%)

320 4 3541 75.06(2.12%) 3462 112.51(3.25%)

320 8 4361 141.29(3.24%) 4437 118.91(2.68%)

320 16 4871 87.67(1.80%) 4725 99.22(2.10%)

320 32 5091 117.09(2.30%) 4814 73.65(1.53%)

3200 2 1396 20.52(1.47%) 1407 93.42(6.64%)

3200 4 3461 102.09(2.95%) 3518 137.55(3.91%)

3200 8 4529 52.08(1.15%) 4374 135.15(3.09%)

3200 16 4698 123.55(2.63%) 4872 122.77(2.52%)

3200 32 4783 255.41(5.34%) 4702 91.68(1.95%)

32000 2 1207 27.88(2.31%) 1274 17.45(1.37%)

32000 4 3352 171.62(5.12%) 3341 169.05(5.06%)

32000 8 4288 84.90(1.98%) 4351 101.81(2.34%)

32000 16 4623 87.37(1.89%) 4651 136.27(2.93%)

32000 32 4695 77.93(1.66%) 4610 108.79(2.36%)

A.3 Gráficosde comparação

Na figuraA.1, pode-sever um gráficodaevoluçãodosvaloresdedesempenhoencontrados

em um experimentosemconcorrência( regravaçãode um arquivo de 3200Kbytesusando

registrode8Kbytes) , paraostrêssistemasdearquivo.

Na figura A.2, pode-sever um gráficoda evoluçãodosvaloresde desempenhoencon-

tradosem um experimentocom concorrência( regravaçãode um arquivo de 3200Kbytes

usandoregistrode8Kbytes) , paraostrêssistemasdearquivo. Pode-senotarqueo sistema

A.3Gráficosdecomparação 82


Ordemdoexperimento

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

50454035302520151050

10000

9000

8000

7000

6000

5000

4000

3000

2000

FiguraA.1: Evoluçãododesempenhodossistemasdearquivo semconcorrência


Ordemdoexperimento

Vaz

ãoob

tida

(Kby

tes/

segu

ndo)

50454035302520151050

5000

4500

4000

3500

3000

2500

2000

1500

1000

500

FiguraA.2: Evoluçãodo desempenhodossistemasdearquivo comconcorrência

Saliusémaisestável queosdemais.

A.4Conclusão 83

A.4 Conclusão

Consideramosqueo númerode instânciasdeexperimentos,50, foi suficientementegrande

parachegarmosavaloresrepresentativosparao desempenhodossistemasdearquivossendo

testados.

a d s a e d erick b. pdocs.computacao.ufcg.edu.br/posgraduacao/disserta... · de especiﬁcação...

Documents