Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba - PDF document

Download presentation
Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba
Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba

Embed / Share - Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba


Presentation on theme: "Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba"— Presentation transcript


roadmapbydiscussingtheanalytical,simulationandex-perimentalapproaches.2.RELATEDWORKInorderfortheon-linebackupprocesstoreadaconsistentstateofthe lesystem,theremustbeawaytospecifytheconsistencyrequirementsoftheapplicationsrunningonthe lesystem.Currentgeneralpurpose lesysteminterfacesprovideweaksemanticsforspecifyingconsistencyrequire-ments.Hence,weseeexistingsolutions[2,3,4,8,9,10,11,14]onlyachievingweakerlevelsofbackup-copyconsistencyi.e.per leconsistencyorinveryspeci ccases,applicationlevelconsistency.Forexample,manymodernday lesystems[8,9,11]anddiskstoragesubsystems[2,3]comewithacopy-on-writebasedsnapshotfacilitythatcreatesapoint-in-time,read-onlycopyoftheentire lesystem,whichthenactsasthesourceforon-linebackup[2,4,3,8,11].Anotherapproachcalled\splitmirror"techniquemaintainsa\mirror"oftheprimary lesystem,whichisperiodically\split"toactasthesourceforbackup[2,4,14].Snapshotsarecreatedandmirrorsare\split"afterbu ersare ushedanda lesystemconsistencycheckisconducted.But, lesystemconsistencycheckisnotcapableofensuringconsistencyacross les.Applicationlevelconsistencyhavebeenachievedusingsnapshot[9]andmirroring[14]solutionsbyincludingtheap-plicationtobeapartofthesnapshotcopyormirror\split-ting"initiationprocess.Suchmethodsareonlypossibleforadvancedapplicationslikedatabases,havingwelldevelopedconsistencyspecifyingmechanismsliketransactions.More-over,thesemethodscanonlyensurebackupconsistencyattheapplicationlevelandanyattemptsofcoordinatinganon-linebackupprocessatthe lesystemlevelwiththecon-sistencymechanismsintheupperlayersofthesoftwarestackisnotanecientoption.Athirdapproachtermedcontinuousdataprotectionmain-tainsabackupofeverychangemadetothedata[4,15],butagainmanagingtoachieveonlyper leconsistency.Stillotherexistingon-line lesystembackupsolutionsoperatebykeepingtrackofopen lesandmaintainconsis-tencyofgroupsof lesthatarepossiblylogicallyrelatedbybackingthemuptogether.Suchgroupsof lesareidenti- edbymonitoringmodi cationfrequenciesacrossopen les[23].Resortingtoheuristicsandadhocconcurrencycontrolmechanismsmayresultinaconsistentbackupcopyonlybyaccident.Recenttimeshaveseenaphenomenalgrowthofunstruc-turedandsemi-structureddatai.e.datastoredin les,with lesspreadacrossmachines,disksanddirectoriesandac-cessedconcurrentlybymyriadofapplications.Withvitaldatastoredin les,amongmanyothermanagementissues,thereisanurgentneedforecientwaystospecifyandmain-taintheconsistencyofthedatainthefaceofconcurrentac-cesses.Recognizingthisneed, lesystemssupportingtrans-actionshavebeenproposedbyanumberofresearchers,[13,16,19,20],anditisverylikelythatTransactionalFileSys-temswillbecomethedefaultinsystems.Wehavethereforeassumedthe lesystemtobebackedup,supportstrans-actionsasamechanismtoensureconsistencyofconcurrentoperations.Now,givena lesystemwithtransactions,thenaturalnextstepwouldbetoborrowon-linedatabasebackupso-lutions.Today'sHotBackup[25]solutionsanditsancestor,thefuzzydump[6]facility,workby rstbackingupa"live"databaseandthenrunningtheredologoineonthebackupcopytoestablishitsconsistency.Similarapproachesfor lesystemswillincurhighperformancecost(writelatency)andisspaceinecientaseachentryinthe lesystemlogwouldhavetorecordbeforeandafterimagesofpossiblyentire les.Hence,weneedtoexploredi erentapproachesforachievinganon-lineconsistentbackupcopyofa lesystem.[17]suggestedaschemewhichconsiderstheon-linebackupofadatabasebyaglobalreadoperation(werefertoitasabackuptransaction)inthefaceofregulartransactionsac-tiveonthedatabase.Thisschemeensuresthatthebackuptransactiondoesnotabort,andactivetransactionsabortiftheydonotfollowcertainconsistencyrules.Theschemesuggestedwasshowntobeinerrorin[1]andtheauthorssuggestedamodi edformofthealgorithmtoensureacon-sistentbackup.Everyentityiscolouredwhitetobeginwith.Whenthebackuptransactionreadsanentity,itscolourturnsblack.Anormaltransactioncanwriteintoentitiesthatareallwhiteorallblack.Atransactionthathaswrit-tenintoanentitythatisofonecolourandthenattemptstowriteintoanotherentityofadi erentcolour,hastoabort.Transactionswritingintowhiteentitiesareaheadofthebackuptransactionintheequivalentserialschedule,whilethetransactionswritingintoblackentitiesareafterthebackuptransactionintheequivalentschedule.Eachentityisalsogivenashadewhichchangesfrompuretoo whenablacktransactionreadsorwritestheentity(whicheverisallowedonit).Restrictionsareplacedonreadingentitieswhoseshadesareo ,bywhitetransactions.Theschemein[17]laysthefoundationofourapproach.But,theschemewasdesignedforadatabaseanditisas-sumedthattwophaselockingistheconcurrencycontrolalgorithm.Ourapproachdescribedinsucceedingsectionsgivesasoundertheoreticalbasisforidentifyingcon ictsandthismakesourapproachindependentofanyparticularcon-currencycontrolalgorithm.Duetospacerestrictionthispa-peronlyprovidesaconceptualexplanationofthetheoreticalbasisofourapproach,butfutureworkcouldmakeavailableformalcorrectnessproofs.Further,weconsidera lesystemasopposedtoadatabasesystem,whichbringsforthissuesuniquetoa lesystem.Forexample, lesystemscatertomanymoreoperationsbesidesreads,writes,deletesandin-sertionsofentities,suchasrename,move,copyetc.Filesinmostpopular lesystemsliketheext2arenotaccesseddi-rectly,butareaccessedafterperforminga\pathlookup"op-eration.Filesystembackupinvolvesbackingupoftheentirenamespaceinformation(directorycontents)alongwiththedatawhichcomplicatesonlinebackupas lesystemnames-paceisconstantlychangingevenasthebackupprocessistraversingit.Moreover, lesystembackupdoesnotjustinvolvethebackupofdatabutincludesbackingupofeach lesmeta-data(e,ginodesofext2).3.SYSTEMMODELAssuminga lesystemthatprovidesacommontransac-tionalinterfacetoallapplicationsrunningonit,theprob-lemofcreatingaconsistentbackupcopyofanactive lesystemnowfundamentallyreducestoaconcurrencycon-trolproblem.But,theproblemprovestobechallengingasthebackupprogramreadstheentire lesystem,andthisisfurtheraggravatedbythefactthatthe lesystemnamespacemaybeactivelychangingevenasthebackup bitofall lesisinitializedto0beforeabackupprogramstarts.But,initializingthereadbitoftheentire lesys-tembeforeeverybackupmaynotbeveryecientandsoasequencenumberofthebackuptransactionmaybeusedinstead,wherethesequencenumberofthepresentbackuptransactionisonegreaterthenitsimmediatepredecessor.Foreaseofdiscussion,wecontinueusingthereadbit.Thebackuptransactiontraversesthe lesystemnamespaceus-ingtraversalalgorithmssuchasdepth rsttraversal,reading lesonitspathtothebackup-copyandasitreadseach leitsetsthereadbitto1.Ausertransactionserializeswithrespecttothebackuptransactionbyestablishingwithitamutuallyserializablerelationshipusingabitcalledthebefore-afterbit,reservedineach\live"usertransaction'shousekeepingdatastruc-ture.Whenausertransactionsucceedstolockits rst leforaccess,itinitializesthebefore-afterbitto1ifthe le'sreadbitis1andto0otherwise.A0storedinthebefore-afterbitmeansthatthetransaction'smutuallyserializableorderisbeforethebackuptransactionanda1indicatesthatitisorderedafterthebackuptransaction.Onsubsequentsuc-cessfullockingofa le,theusertransactionveri eswhetheritcontinuestobemutuallyserializablewithrespecttothebackuptransactionbycomparingthereadbitofthe lewithitsownbefore-afterbit.Thefollowingtableenumeratesmu-tuallyserializablechecking. before-afterbit readbit mutuallyserializable 1 1 yes 1 0 no 0 1 no 0 0 yes Ifamutuallynonserializableoperationisdetectedthenthecon ictmustberesolvedbeforetheexecutionoftheusertransactioncanproceed.Now,mutuallynonserializabletransactionshaveaccessedortriedtoaccessbothread(1)andunread(0) les.LetTmcbetheusertransactionmutu-allynonserializablewiththebackuptransaction.Onewayofresolvingthecon ictistorollbackthebackuptransac-tion's\read"ofthe lesmarked1andpresentlyaccessedbyTmc.Rollingbackthe\reads"of lesessentiallymeanstomarkthem0(unread)andtoremovethemfromthebackup-copy.Thebackuptransactionwillre-readthemlater.Un-fortunately,althoughthissolutiondoesnothampertheex-ecutionofusertransactions,itmayleadtoacascadingrollbackofbackup\reads"asrollbacksmayrenderpreviouslyconsistenttransactionstonowbemutuallynonserializable.Intheworstcasescenario,thebackuptransactionhastoberestarted.AnothermethodofhandlingtheproblemistoabortandrestartTmc\hoping"thebackuptransactioncompletesread-ingthe\unread" lesaccessedbyTmc.Thesolutionseemsquiteattractiveinascenariowhereusertransactionsdonothaveahardtimeconstraint.But,ifconcurrencycontrolmechanismslikeasimpletwo-phaselockingisusedbyusertransactions,anabortmayleadtocascadingaborts.Athirdsolutionforresolvingcon ictsistopauseTmcwhenpossible.Ifthetransactionhasaccesseda lealreadyreadbythebackuptransactionanditthenneedstoaccessanother lewhichthebackuptransactionhasnotyetread,thenthetransactioncouldbemadetowaitandthebackuptransactionsignalledtoreadthis leimmediately.Thus,oneofthecon ictresolvingtechniquesoracom-binationoftechniquesdiscussedabovehavetobeemployeddependingonissuesliketheunderlyingconcurrencycontrolmechanismforusertransactionsandatransaction'sbefore-afterbitstatus,toensuremutualserializabilitywiththebackuptransaction.Therearemanyother lesoperationssuchasappend,truncate,create,unlink,andoperationsthatoperateonthe le'sdescriptor,suchasownership,accesspermissionsetc.Further,thereareanumberof letypessuchasregular les,directories,special les,etc.(weareusingLinuxterminol-ogyandnotde ningtheseitems,toconservespace).Formostofthem,wehaveshownthattheycanbetreatedasequivalenttoanupdateofanordinary le.Thus,forexam-ple,creatinga leisequivalenttowritingtothedirectoryunderwhichthe leistobecreated.However,specialtreatmentmayberequiredwhendealingwithdirectories.Considertwodirectoriesd1andd2withd2havingachilddirectoryd3.Suppose,thebackuptransaction(BT)readsd1,andthenreadsd2.Beforeitcanreadd3,anothertransactionTA,movesd3fromunderd2tounderd1.TransactionTAismutuallyserializablewithrespecttoBTwithorderas"after"andsoitisallowedtoproceed.Butthend3willnotbeinthebackupasBThasalreadytraverseditspartofthe lesystemnamespace,andtherewillbeadanglingreferencetoitinthebackedupversionofd2.Oneofthesolutionsweareexploringistoensurethatallreadsaredone"bottomup"byBT.Inthisexample,d3willhavetobereadbefored2andthemoveofd3fromd2tod1byTAwillbeallowedonlyafterBThasreadd2also.Weintendtoformallyprovecorrectnessofthisrestrictionandweintendtoconsiderotheralternativesalso.Overallperformanceduringanon-linebackupusingourapproachcanbeconsiderablyimprovedifcon ictsbetweenusertransactionsandthebackuptransactioncanbekeptlow.Mostapplicationsrunningonasystemdevelopapat-ternof leaccess.Storingthehistoryof leaccessesandthenusingthesepatternstodirectthebackupprogramawayfromactiveregionse ectivelyreducescontention.Filesys-temtracescollectedoveraperiodoftimeisalsolikelytoshowgroupsof lesthatareaccessedtogetherandhencearepossiblyrelated.Backupofsuchgroupsmaybetakentogethertoimproveperformance.Studiesshowthatonlyabout1%ofall lesareuseddaily[5],thusevenwithoutusingcon ictreducingheuristicsdis-cussedabove,con ictswillberare.Weneedtoshowexper-imentallythatthisisindeedthecase.4.CONCLUSIONANDFUTUREWORKThispaperarguesthatbackupsof lesystemsmusten-sureconsistencyandforthis,atransactional lesystemisrequired.Currenttechniquesofhotbackupsdonoten-sureconsistentbackups.Usingstandardconcurrencycon-troltechniquesforbackupintransactional lesystemscanbeinecientasthebackupprocess,consideredasatrans-action,hastoaccessevery leinthesystem.Abortingthistransactionwillbeexpensive,andothertransactionsmayexperiencefrequentabortsbecauseofthistransaction.Weinformallyshowthatasimplerestrictionofconsideringeveryoperationofnormaltransactions(beitareadorawrite)tocon ictwithareadofthesame lebythebackuptransactionresultsinaschemeinwhichensuringthatthebackuptransactionismutuallyserializablewitheveryothertransactionresultsinaconsistentbackupcopy.Thebackup

By: kittie-lecroy
Views: 135
Type: Public

Online Consistent Backup in Transactional File Systems Lipika Deka and Gautam Ba - Description


dekaiitgernetin gbiitgernetin ABSTRACT A consistent backup preserving data integrity across 64257les in a 64257le system is of utmost importance for the purpose of correctness and minimizing system downtime during the process of data recovery With th ID: 1456 Download Pdf

Related Documents