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 The PPT/PDF document "Online Consistent Backup in Transactiona..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
roadmapbydiscussingtheanalytical,simulationandex-perimentalapproaches.2.RELATEDWORKInorderfortheon-linebackupprocesstoreadaconsistentstateofthelesystem,theremustbeawaytospecifytheconsistencyrequirementsoftheapplicationsrunningonthelesystem.Currentgeneralpurposelesysteminterfacesprovideweaksemanticsforspecifyingconsistencyrequire-ments.Hence,weseeexistingsolutions[2,3,4,8,9,10,11,14]onlyachievingweakerlevelsofbackup-copyconsistencyi.e.perleconsistencyorinveryspeciccases,applicationlevelconsistency.Forexample,manymoderndaylesystems[8,9,11]anddiskstoragesubsystems[2,3]comewithacopy-on-writebasedsnapshotfacilitythatcreatesapoint-in-time,read-onlycopyoftheentirelesystem,whichthenactsasthesourceforon-linebackup[2,4,3,8,11].Anotherapproachcalled\splitmirror"techniquemaintainsa\mirror"oftheprimarylesystem,whichisperiodically\split"toactasthesourceforbackup[2,4,14].Snapshotsarecreatedandmirrorsare\split"afterbu ersare ushedandalesystemconsistencycheckisconducted.But,lesystemconsistencycheckisnotcapableofensuringconsistencyacrossles.Applicationlevelconsistencyhavebeenachievedusingsnapshot[9]andmirroring[14]solutionsbyincludingtheap-plicationtobeapartofthesnapshotcopyormirror\split-ting"initiationprocess.Suchmethodsareonlypossibleforadvancedapplicationslikedatabases,havingwelldevelopedconsistencyspecifyingmechanismsliketransactions.More-over,thesemethodscanonlyensurebackupconsistencyattheapplicationlevelandanyattemptsofcoordinatinganon-linebackupprocessatthelesystemlevelwiththecon-sistencymechanismsintheupperlayersofthesoftwarestackisnotanecientoption.Athirdapproachtermedcontinuousdataprotectionmain-tainsabackupofeverychangemadetothedata[4,15],butagainmanagingtoachieveonlyperleconsistency.Stillotherexistingon-linelesystembackupsolutionsoperatebykeepingtrackofopenlesandmaintainconsis-tencyofgroupsoflesthatarepossiblylogicallyrelatedbybackingthemuptogether.Suchgroupsoflesareidenti-edbymonitoringmodicationfrequenciesacrossopenles[23].Resortingtoheuristicsandadhocconcurrencycontrolmechanismsmayresultinaconsistentbackupcopyonlybyaccident.Recenttimeshaveseenaphenomenalgrowthofunstruc-turedandsemi-structureddatai.e.datastoredinles,withlesspreadacrossmachines,disksanddirectoriesandac-cessedconcurrentlybymyriadofapplications.Withvitaldatastoredinles,amongmanyothermanagementissues,thereisanurgentneedforecientwaystospecifyandmain-taintheconsistencyofthedatainthefaceofconcurrentac-cesses.Recognizingthisneed,lesystemssupportingtrans-actionshavebeenproposedbyanumberofresearchers,[13,16,19,20],anditisverylikelythatTransactionalFileSys-temswillbecomethedefaultinsystems.Wehavethereforeassumedthelesystemtobebackedup,supportstrans-actionsasamechanismtoensureconsistencyofconcurrentoperations.Now,givenalesystemwithtransactions,thenaturalnextstepwouldbetoborrowon-linedatabasebackupso-lutions.Today'sHotBackup[25]solutionsanditsancestor,thefuzzydump[6]facility,workbyrstbackingupa"live"databaseandthenrunningtheredologoineonthebackupcopytoestablishitsconsistency.Similarapproachesforlesystemswillincurhighperformancecost(writelatency)andisspaceinecientaseachentryinthelesystemlogwouldhavetorecordbeforeandafterimagesofpossiblyentireles.Hence,weneedtoexploredi erentapproachesforachievinganon-lineconsistentbackupcopyofalesystem.[17]suggestedaschemewhichconsiderstheon-linebackupofadatabasebyaglobalreadoperation(werefertoitasabackuptransaction)inthefaceofregulartransactionsac-tiveonthedatabase.Thisschemeensuresthatthebackuptransactiondoesnotabort,andactivetransactionsabortiftheydonotfollowcertainconsistencyrules.Theschemesuggestedwasshowntobeinerrorin[1]andtheauthorssuggestedamodiedformofthealgorithmtoensureacon-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,weconsideralesystemasopposedtoadatabasesystem,whichbringsforthissuesuniquetoalesystem.Forexample,lesystemscatertomanymoreoperationsbesidesreads,writes,deletesandin-sertionsofentities,suchasrename,move,copyetc.Filesinmostpopularlesystemsliketheext2arenotaccesseddi-rectly,butareaccessedafterperforminga\pathlookup"op-eration.Filesystembackupinvolvesbackingupoftheentirenamespaceinformation(directorycontents)alongwiththedatawhichcomplicatesonlinebackupaslesystemnames-paceisconstantlychangingevenasthebackupprocessistraversingit.Moreover,lesystembackupdoesnotjustinvolvethebackupofdatabutincludesbackingupofeachlesmeta-data(e,ginodesofext2).3.SYSTEMMODELAssumingalesystemthatprovidesacommontransac-tionalinterfacetoallapplicationsrunningonit,theprob-lemofcreatingaconsistentbackupcopyofanactivelesystemnowfundamentallyreducestoaconcurrencycon-trolproblem.But,theproblemprovestobechallengingasthebackupprogramreadstheentirelesystem,andthisisfurtheraggravatedbythefactthatthelesystemnamespacemaybeactivelychangingevenasthebackup bitofalllesisinitializedto0beforeabackupprogramstarts.But,initializingthereadbitoftheentirelesys-tembeforeeverybackupmaynotbeveryecientandsoasequencenumberofthebackuptransactionmaybeusedinstead,wherethesequencenumberofthepresentbackuptransactionisonegreaterthenitsimmediatepredecessor.Foreaseofdiscussion,wecontinueusingthereadbit.Thebackuptransactiontraversesthelesystemnamespaceus-ingtraversalalgorithmssuchasdepthrsttraversal,readinglesonitspathtothebackup-copyandasitreadseachleitsetsthereadbitto1.Ausertransactionserializeswithrespecttothebackuptransactionbyestablishingwithitamutuallyserializablerelationshipusingabitcalledthebefore-afterbit,reservedineach\live"usertransaction'shousekeepingdatastruc-ture.Whenausertransactionsucceedstolockitsrstleforaccess,itinitializesthebefore-afterbitto1ifthele'sreadbitis1andto0otherwise.A0storedinthebefore-afterbitmeansthatthetransaction'smutuallyserializableorderisbeforethebackuptransactionanda1indicatesthatitisorderedafterthebackuptransaction.Onsubsequentsuc-cessfullockingofale,theusertransactionverieswhetheritcontinuestobemutuallyserializablewithrespecttothebackuptransactionbycomparingthereadbitofthelewithitsownbefore-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"ofthelesmarked1andpresentlyaccessedbyTmc.Rollingbackthe\reads"oflesessentiallymeanstomarkthem0(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.Ifthetransactionhasaccessedalealreadyreadbythebackuptransactionanditthenneedstoaccessanotherlewhichthebackuptransactionhasnotyetread,thenthetransactioncouldbemadetowaitandthebackuptransactionsignalledtoreadthisleimmediately.Thus,oneofthecon ictresolvingtechniquesoracom-binationoftechniquesdiscussedabovehavetobeemployeddependingonissuesliketheunderlyingconcurrencycontrolmechanismforusertransactionsandatransaction'sbefore-afterbitstatus,toensuremutualserializabilitywiththebackuptransaction.Therearemanyotherlesoperationssuchasappend,truncate,create,unlink,andoperationsthatoperateonthele'sdescriptor,suchasownership,accesspermissionsetc.Further,thereareanumberofletypessuchasregularles,directories,specialles,etc.(weareusingLinuxterminol-ogyandnotdeningtheseitems,toconservespace).Formostofthem,wehaveshownthattheycanbetreatedasequivalenttoanupdateofanordinaryle.Thus,forexam-ple,creatingaleisequivalenttowritingtothedirectoryunderwhichtheleistobecreated.However,specialtreatmentmayberequiredwhendealingwithdirectories.Considertwodirectoriesd1andd2withd2havingachilddirectoryd3.Suppose,thebackuptransaction(BT)readsd1,andthenreadsd2.Beforeitcanreadd3,anothertransactionTA,movesd3fromunderd2tounderd1.TransactionTAismutuallyserializablewithrespecttoBTwithorderas"after"andsoitisallowedtoproceed.Butthend3willnotbeinthebackupasBThasalreadytraverseditspartofthelesystemnamespace,andtherewillbeadanglingreferencetoitinthebackedupversionofd2.Oneofthesolutionsweareexploringistoensurethatallreadsaredone"bottomup"byBT.Inthisexample,d3willhavetobereadbefored2andthemoveofd3fromd2tod1byTAwillbeallowedonlyafterBThasreadd2also.Weintendtoformallyprovecorrectnessofthisrestrictionandweintendtoconsiderotheralternativesalso.Overallperformanceduringanon-linebackupusingourapproachcanbeconsiderablyimprovedifcon ictsbetweenusertransactionsandthebackuptransactioncanbekeptlow.Mostapplicationsrunningonasystemdevelopapat-ternofleaccess.Storingthehistoryofleaccessesandthenusingthesepatternstodirectthebackupprogramawayfromactiveregionse ectivelyreducescontention.Filesys-temtracescollectedoveraperiodoftimeisalsolikelytoshowgroupsoflesthatareaccessedtogetherandhencearepossiblyrelated.Backupofsuchgroupsmaybetakentogethertoimproveperformance.Studiesshowthatonlyabout1%ofalllesareuseddaily[5],thusevenwithoutusingcon ictreducingheuristicsdis-cussedabove,con ictswillberare.Weneedtoshowexper-imentallythatthisisindeedthecase.4.CONCLUSIONANDFUTUREWORKThispaperarguesthatbackupsoflesystemsmusten-sureconsistencyandforthis,atransactionallesystemisrequired.Currenttechniquesofhotbackupsdonoten-sureconsistentbackups.Usingstandardconcurrencycon-troltechniquesforbackupintransactionallesystemscanbeinecientasthebackupprocess,consideredasatrans-action,hastoaccesseveryleinthesystem.Abortingthistransactionwillbeexpensive,andothertransactionsmayexperiencefrequentabortsbecauseofthistransaction.Weinformallyshowthatasimplerestrictionofconsideringeveryoperationofnormaltransactions(beitareadorawrite)tocon ictwithareadofthesamelebythebackuptransactionresultsinaschemeinwhichensuringthatthebackuptransactionismutuallyserializablewitheveryothertransactionresultsinaconsistentbackupcopy.Thebackup