a d s a e d erick b. pdocs.computacao.ufcg.edu.br/posgraduacao/disserta... · de especificação...
TRANSCRIPT
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
5.14 Desempenhocomparativo para gravaçõessíncronasde um arquivo de
32Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.15 Desempenhocomparativo para gravaçõessíncronasde um arquivo de
32000Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . 56
5.16 Desempenhocomparativo para gravaçõessíncronasde um arquivo de
32000Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . 57
5.17 Desempenhocomparativo para regravaçõessíncronasde um arquivo de
32Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.18 Desempenhocomparativo para regravaçõessíncronasde um arquivo de
32Kbytescomconcorrência . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.19 Desempenhocomparativo para regravaçõessíncronasde um arquivo de
32000Kbytessemconcorrência. . . . . . . . . . . . . . . . . . . . . . . . 58
5.20 Desempenhocomparativo para regravaçõessíncronasde um arquivo de
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
abertassimultaneamente. . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.23 Desempenhocomparativo do servidorde correioeletrônicocom 20 seções
abertassimultaneamente. . . . . . . . . . . . . . . . . . . . . . . . . . . 64
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
2.3SistemasdeArquivo 11
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.
2.3SistemasdeArquivo 12
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
2.3SistemasdeArquivo 13
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
2.3SistemasdeArquivo 14
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
2.3SistemasdeArquivo 15
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.
2.3SistemasdeArquivo 16
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-
2.3SistemasdeArquivo 17
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.
4.1SistemadeArquivosEXT2 28
� 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;
4.1SistemadeArquivosEXT2 29
� 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
4.4Gravaçãoestávelpassoa passo 39
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,
4.4Gravaçãoestávelpassoa passo 40
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.2Descriçãodosexperimentos 44
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
5.2Descriçãodosexperimentos 45
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-
5.3Resultadose análise 47
200
400
600
800
1000
1200
1400
1600
1 10 100
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
Figura5.1: Desempenhodo sistemaExt2emgravaçõessíncronassemconcorrência
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
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.
5.3Resultadose análise 48
0
500
1000
1500
2000
2500
3000
3500
1 10 100
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
Figura5.3: Desempenhodo sistemaExt2emregravaçõessíncronassemconcorrência
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 49
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:
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 50
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
100101
130120110100908070605040
Figura5.6: Desempenhodo sistemaReiserFSemgravaçõessíncronascomconcorrência
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 51
Arquivo de32000KbytesArquivo de3200Kbytes
Arquivo de320KbytesArquivo de32Kbytes
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 52
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)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
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.
5.3Resultadose análise 53
1000
1500
2000
2500
3000
3500
4000
4500
5000
5500
1 10 100
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
Figura5.10:DesempenhodosistemaSaliusemgravaçõessíncronascomconcorrência
4000
5000
6000
7000
8000
9000
10000
1 10 100
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
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.
5.3Resultadose análise 54
1000
1500
2000
2500
3000
3500
4000
4500
5000
5500
1 10 100
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
Tamanhodecadaregistro(KBytes)
Arquivo de32KbytesArquivo de320Kbytes
Arquivo de3200KbytesArquivo de32000Kbytes
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.
5.3Resultadose análise 55
Gráficos comparandoa performancedegravação
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 56
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
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)
Tamanhodecadaregistro(KBytes)
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-
5.3Resultadose análise 57
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
100101
500045004000350030002500200015001000500
0
Figura 5.16: Desempenhocomparativo para gravaçõessíncronasde um arquivo de
32000Kbytescomconcorrência
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
100101
10000900080007000600050004000300020001000
0
Figura5.17:Desempenhocomparativo pararegravaçõessíncronasdeumarquivo de32Kby-
tessemconcorrência
5.3Resultadose análise 58
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
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)
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 59
EXT2FSSaliusFSReiserFS
Tamanhodecadaregistro(KBytes)
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
5.3Resultadose análise 60
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.3Resultadose análise 61
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.
5.3Resultadose análise 62
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
5.3Resultadose análise 63
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
5.3Resultadose análise 64
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
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)
Tamanhodecadamensagem(KBytes)
qmail sobreReiserFSqmail sobreEXT2
qmail sobreSalius
Figura 5.23: Desempenhocomparativo do servidorde correio eletrônicocom 20 seções
abertassimultaneamente
5.3Resultadose análise 65
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:
Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)
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:
Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)
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
Resultadosparaosexperimentoscomconcorrência:
Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)
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:
Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)
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
Resultadosparaosexperimentoscomconcorrência:
Arquivo (KB) Registro(KB) Write (KB/s) q (%) Rewrite (KB/s) q (%)
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
EXT2FSSaliusFSReiserFS
Ordemdoexperimento
Vaz
ãoob
tida
(Kby
tes/
segu
ndo)
50454035302520151050
10000
9000
8000
7000
6000
5000
4000
3000
2000
FiguraA.1: Evoluçãododesempenhodossistemasdearquivo semconcorrência
EXT2FSSaliusFSReiserFS
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.