NO312529B1 - Lagring av data - Google Patents

Description

Foreliggende oppfinnelse angår hierarkisk lagringskontroll av datafiler.

Mengden data lagret på harddisker, som fungerer som masselagre på personlige datamaskiner, har øket hurtig over de siste ti år. Dette gjelder spesielt data på nettverksfllservere hvor harddisk-delsystemer på 1 GB (gigabyte) eller mer, som omfatter flere tusen filer, nå er vanlige.

Mange av filene av på en nettverksfilserver vil ikke ha vært aksessert på lenge. Dette kan skyldes en rekke årsaker: filen kan være en gammel versjon, en sikkerhetskopi, eller den kan ha blitt tatt vare på i tilfellet det skulle bli behov for den en dag. Filen kan faktisk være fullstendig overflødig, men bare eieren av filen kan slå dette fast, og derfor blir filen tatt vare på av sikkerhetsgrunner. God datamaskinpraksis tilsier at dersom en er i tvil, bør filen tas vare på. Den naturlig konsekvens av dette er at harddisker fylles opp med gamle filer. Dette skjer i praktisk talt alle mikroprosessorbaserte personlige datasystemer, fra de minste til største.

Hierarkisk lagringsstyring (HSM) er en kjent teknikk for å løse dette problemet. De fleste operativsystemer fører en fortegnelse over siste dato og tid en fil ble oppdatert (dvs. skrevet til). Mange fører også en liste over den siste dato og tid en fil ble aksessert (dvs. lest fra). Et HSM-system går igjennom listen over filer på en harddisk periodisk, og sjekker siste dato/tid hver enkelt ble aksessert. Hvis en fil ikke har vært i bruk i løpet av et forhåndsbestemt tidsrom (typisk 1 til 6 måneder), arkiveres filen, dvs. den overføres til et sekundært lager, slik som et magnetbånd, og slettes fra harddisken.

HSM er vanligvis integrert med sikkerhetskopiering. Ta som eksempel et magnetbåndsikkerhetskopieringsssytem med HSM-fasiliteter hvor inaktivitetsterskelen er satt til 3 måneder. Sikkerhetskopieringen kjøres periodisk (typisk ukentlig eller oftere) og registrerer at siste aksessdato for en gitt fil er lenger enn 3 måneder siden. Sikkerhetskopieringssystemet passer på at det har f. eks. tre sikkerhetskopier av filen på forskjellige magnetbånd (eller venter til et senere tilfelle, hvor den har tre kopier) og sletter så filen. Skulle det noen gang være behov for filen kan brukeren simpelthen gjenfinne den fra en av de tre sikkerhetskopibåndene. Sikkerhetskopieringssystemet må sørge for at magnetbåndene som inneholder de arkiverte kopier av filen ikke overskrives. Denne metoden skaffer til veie en langsiktig løsning på problemet, siden magnetbånd kan fjernes, enkelt kan erstattes og er billige.

Så snart en fil er slettet av et HSM-system, er den ikke lenger synlig på den originale disken. Dette kan være en ulempe dersom en bruker eller en applikasjon senere bestemmer at tilgang til filen er nødvendig, siden intet spor av filen vil bli funnet ved søk på disken. Brukeren eller applikasjonen kan dermed ikke vite at filen kan gjenfinnes fra en sikkerhetskopi, og en applikasjon kan som et resultat av dette gi hva som helst fra villedende informasjon til en fatal feil.

Ideelt, istedenfor å fjernes uten å etterlate spor, burde filen fortsatt være listet i diskens filkatalog (fortrinnsvis ved hjelp av metoder for å identifisere at den er flyttet til sikkerhetskopi eller sekundært lager), men uten at den faktiske datafilen er tilstede og tar opp diskplass. Denne fasiliteten finnes nå faktisk i mange HSM-systemer og er kjent som migrasjon. HSM-systemet etterlater de vanligvis filreferansen i tilkatalogen, og erstatter fildataene enten med en liten "stubb" som inneholder identiteten til det stedet der den migrerte filen kan gjenfinnes, eller sletter dataene fullstendig og etterlater en fil med null lengde.

En ytterligere forbedring av HSM-systemer, kjent som de-migrasjon, får HSM-systemet til automatisk å gjenopprette en migrert fil på den originale disken dersom en bruker eller applikasjon forsøker å aksessere. Det er åpenbart at dette kun er mulig dersom det sekundære lagringsmedium som inneholder den migrerte filen er kontinuerlig tilkoblet systemet. Når migrerte data lagres på en slik "nærlinje"-enhet, f. eks. en optisk disk-jukeboks, kan forespørselen om aksess til filen til og med settes til å vente midlertidig inntil filen er et gjenopprettet, hvorpå den får fortsette som om filen aldri hadde vært migrert.

HSM-teknikkene beskrevet over er effektive når de anvendes i forbindelse med store antall av relativt små filer brukt av bare en bruker om gangen. Imidlertid kan det tenkes et databasesystem hvor et flertall brukere har tilgang til en enkelt stor databasefil som inneholder kundenavn og adressefortegnelser og tilsvarende historiske data. Siden nye kundefortegnelser stadig legges til og fortegnelser over kunder endres, er filen aldri kandidat for migrasjon, siden den alltid må være tilgjengelig. Ikke desto mindre vil en slik fil typisk ha mange fortegnelser over gamle passive kunder hvor detaljene må beholdes for mulig fremtidig referanse, men hvor fortegnelsene ellers forblir ubenyttet i lange tidsperioder. Diskplassen som fylles av slike passive fortegnelser kan ofte representere mesteparten av den plassen hele filen opptar.

Det er allerede kjent å ha filer med direkte tilgang, hvor små mengder data kan skrives til eller leses fra en hvilken som helst del av filen. Når en ny direkte tilgangsfil opprettes har filen null lengde til det skrives data til den. Siden filen har direkte tilgang, trenger ikke nødvendigvis de første data som skrives til den være ved offset null (dvs. ved begynnelsen av filen), de kan skrives til en hvilken som helst posisjon. F. eks. kan 10 byte med data skrives fra offset 1000. Filen vil da ha en logisk lengde på 1010 bytes selv om bare 10 bytes faktisk er skrevet. Noen operativsystemer håndterer denne situasjonen ved automatisk å fylle inn de "manglende" 1000 byte med 0 eller tilfeldige tegn, og dermed tildele 1010 bytes selv om bare 10 faktisk ble skrevet.

Avanserte operativsystemer, slik som de som benyttes av nettverksfilservere, støtter konseptet med spredte filer, hvor diskplass kun tildeles de deler av en fil der data faktisk er skrevet. Vanligvis oppnås dette ved å utvide filallokeringstabellen (et kart over hvordan filer er lagret på disken) slik at enhver innføring, som indikerer den neste plassering hvor data for et bestemt felt er lagret, også omfatter en verdi som indikerer den logiske offset hvor dataene begynner. I det ovennevnte eksempel ville derfor første innføring indikere at data begynner ved posisjon x på disken, og at den første byte er ved logisk offset 1000 i filen (i en "normal" fil ville den logiske offset være 0). De delene av en spredt fil der ingen data er skrevet kalles hull.

Oppfinnelsen i sine forskjellige aspekter er definert i de selvstendige krav. Fordelaktige trekk ved oppfinnelsen presenteres i de tilknyttede krav.

I den foretrukne utførelse av oppfinnelsen som skal beskrives under, med henvisning til tegningene, opprettes og vedlikeholdes en tilleggsdatabase som indikerer hvilke datablokker som har vært aksessert, og på hvilke datoer. Ikke-aksesserte blokker kan så arkiveres og slettes fra diskfilen for å redusere lagringsbehovet. Slettingen kan gjøres ved å justere filallokeringstabellen slik at filen behandles som en spredt fil.

Dersom det gjøres en forespørsel om å lese fra en del av filen som har blitt arkivert, eller migrert, vil systemet de-migrere den etterspurte fildelen før leseforespørselen tilfredsstilles.

Imidlertid vil fortegnelser som nylig har blitt aksessert allerede være på harddisken og kan aksesseres øyeblikkelig ved en senere forespørsel. Dermed vil poster som ofte etterspørres være lett tilgjengelig uten at det er nødvendig å opprettholde hele filen på harddisken.

Metoden kan utvides ved, i praksis, å øke inaktivitetsterskelen til tilleggsdatabasens levetid. Hvis bare et lite antall poster aksesseres i en stor databasefil, kan alle de aksesserte poster lagres på harddisken, uavhengig av den dato de sist ble aksessert. De poster som ikke er aksessert kan imidlertid slettes for å frigjøre diskplass. I dette tilfellet trenger ikke tilleggsdatabasen inneholde dato eller dato/tid for siste aksess. Ved lange intervaller, f. eks. hver måned, kan alle aksesserte områder migreres og tilleggsdatabasen tømmes.

Metoden kan brukes sammen med den delvise fillagringsmetode fra ovenfor nevnte søknad. Tilleggsdatabasen må da i tillegg inneholde informasjon om hvorvidt filene ble aksessert for skriving, slik at data kan ha blitt endret, eller bare for lesing. Den delvise filsikkerhetskopieringsmetode fra ovenfor nevnte søknad gjør ingenting for å frigjøre plass på harddisken, mens den lot de poster som mest sannsynlig ville bli aksessert igjen forbli tilgjengelige.

Oppfinnelsen vil nå beskrives i detalj i form av et eksempel, under henvisning til de vedlagte tegninger, hvor: Figur 1 er et blokkdiagram av et personlig datamaskinsystem med en magnetbåndstasjon; Figur 2 er et diagram som illustrerer aksess til en fil; Figur 3 er et flytdiagram som illustrerer en filaksessoperasjon i overensstemmelse med oppfinnelsen; Figur 4 er et diagram som tilsvarer figur 2 og som illustrerer tildeler som skal opprettholdes på harddisken; Figur 5 er et flytdiagram som illustrerer en sikkerhetskopieringsoperasjon i overensstemmelse med oppfinnelsen, implementert ved det hierarkiske lagringsstyringssystemet; Figur 6 er et flytdiagram som illustrerer en leseaksessoperasjon på en fil som er delvis arkivert; Figur 7 er et diagram som illustrerer en del av minnekartet på operativsystemnivået til en konvensjonell personlig datamaskin; Figur 8 er et diagram som illustrerer en tilsvarende del av minnekartet i metoden ifølge oppfinnelsen. Figur 1 av tegningene viser en personlig datamaskin (PC) 10 som omfatter en sentral mikroprosessor (CPU) 12, et direktetilgangsminne (RAM) 14, og en masselagringsenhet i form av en harddisk 16. Den personlige datamaskinen er også utrustet med en magnetbåndenhet 18 som sørger for sekundærlagring for sikkerhetskopiering og arkivering.

Ved bruk lagrer direktetilgangsminnet 14 instruksjoner som tilføres den sentrale mikroprosessorenhet 12 for å kontrollere operasjonen av denne. Noen av disse instruksjonene kommer fra operativsystemet direkte, og noen initieres av applikasjonsprogrammet som kjøres på datamaskinen.

Generelt opprettholder operativsystemer en filallokeringstabell (FAT) som fører en fortegnelse over den fysiske plassering på harddisken av hver datablokk. I tillegg fører operativsystemet en fortegnelse i forhold til hver enkelt fil over arkivflagg som settes når filen endres og som kan slettes når filen sikkerhetskopieres. Eksisterende sikkerhetskopieringssystemer bruker arkivflagget for å avgjøre om en fil har blitt modifisert og derfor må sikkerhetskopieres.

Et hierarkisk lagringsstyringssystem som automatisk sikkerhetskopierer enhver fil som ikke har vært aksessert i løpet av en spesifisert periode til magnetbånd, kan benyttes.

I den foretrukne utførelse av denne oppfinnelse opprettholdes en tilleggsdatabase, som indikerer, for hver fil, hvilke datablokker som har vært aksessert og på hvilke datoer, slik at det hierarkiske lagringsstyirngssystemet periodisk kan arkiverer eller migrere de blokker som ikke har blitt aksessert. Disse blokkene kan så slettes og lagringsbehovene dermed reduseres. Det kan tenkes en fil opprinnelig 125 byte lang, som inneholder 5 poster hver 25 byte. 1. januar 1995 opprettes en tilleggsdatabase for å oppfange forespørsler om aksess til eksisterende poster i, eller om å lagre en ny post til, filen. Forespørselen over en gitt periode, f. eks. mellom 1. januar og 10. april 1995 kunne være:

21. januar 1995 - ny post lagt til, plassert ved offset 125, lengde 25 byte.

3. februar 1995 - gammel post aksessert (lest), plassert ved offset 25, lengde 25 byte. 15. februar 1995 - gammel post aksessert (lest), plassert ved offset 75, lengde 25 byte.

3. april 1995 - ny post lagt til, plassert ved offset 150, lengde 25 byte.

Når en forespørsel oppfanges, lagres datoen, postens posisjon i filen, og postens lengde i tilleggsdatabasen, på følgende måte:

Det må selvfølgelig være mulig å identifisere den filen som faktisk etterspørres.

Det antas her at en egen tilleggsdatabase opprettholdes for hver fil. I praksis kan

det være å foretrekke å opprettholde en separat tilleggsdatabase for hver underkatalog, i hvilket tilfelle filen også må identifiseres innenfor databasen. Dette reduserer imidlertid antallet tilleggsdatabaser, og således antallet tilleggsfiler som opprettes. I prinsippet kan én enkelt tilleggsdatabase dannes for hele disken. Alle filområder som ikke er inkludert i tilleggsdatabasen illustrert i tabell 1 har ikke vært aksessert i det hele tatt. Dagnummeret er simpelthen en teller som representerer dagene som har gått siden en tilfeldig startdato, i dette tilfellet 1. januar 1995.1 et mer sofistikert system kan både dato og tid (dato/tid) inkluderes.

Figur 2 illustrerer filen i form av et diagram, hvor skraverte områder representerer fildata som har blitt lest eller skrevet, og hvite områder representerer data som ikke har vært aksessert.

De trinn som gjennomgås for hver aksess, er slik som vist i figur 3. Trinn 20 indikerer at aksess etterspørres. Dette kan være en leseaksess eller en skriveaksess. Filen identifiseres først, trinn 22, og start-offset og aksesslengde identifiseres, trinn 24.1 trinn 26 lagres disse data i en tilleggsdatabase, sammen med dato, som vist i tabell 1. Trinn 26 omfatter fordelaktig en konsolideringsoperasjon som sikrer at tilleggsdatabasen ikke inneholder redundant informasjon. F. eks. kan etterfølgende tilganger duplisere eller overlappe tidligere tilganger. Når disse trinn er fullført, vil den opprinnelig ønskede filaksess gjennomføres, trinn 28, hvorved rutinen er fullført, trinn 30.

Disse trinn gjennomføres for hver aksess, og derfor vil filen den 10. april være 175 byte i lengde og inneholde 7 poster, mens tilleggsdatabasen ser ut som tabell 1

over. I løpet av overvåkningsperioden (79 dager) vil de postene som ikke ble aksessert i det hele tatt være opplagte kandidater for arkivering. La oss imidlertid anta at alle poster som ikke har vært aksessert de siste 60 dager, skal arkiveres.

Postene sorteres ved først å anta at hele filen skal migreres til sekundært lager, og deretter å søke gjennom hele tilleggsdatabasen etter alle poster med et dagnummer på 34739 eller større (34739 er 60 dager før 10. april, som er dag 34799). Alle poster med et dagnummer som oppfyller dette kriterium identifiseres, og de deler av filen som inneholder dem, merkes slik at de ikke er kandidater for migrasjon. Alle deler av filen som ikke merkes er således klare for migrasjon.

Av de fire postene aksessert mellom 1. januar og 10. april 1995, vil bare de to siste, gjort henholdsvis 15. februar og 10. april 1995, ha et dagnummer på minst 34739. Derfor vil bare de to siste postene beholdes, idet resten av filen - de delene som er definert som byte 0 til 74 og byte 100 til 149 - er klar for migrasjon. Dette illustreres i et diagram i figur 4, hvor postene som skal beholdes vises skravert og postene som skal migreres er hvite. Dataområdene av filen som skal migreres kopieres nå til den sekundære lagringsenheten ved bruk av normal HSM-prosedyre. Detaljer angående plassering og lengde for hver post beholdes av HSM-systemet for å muliggjøre senere gjenoppretting. I tillegg kan tilleggsdatabasen reduseres for å fjerne et hvert spor av poster med dagnummer mindre enn 34739, for derved å hindre ukontrollert utvidelse av størrelsen til tilleggsdatabasen.

For å oppnå noen fordel ved migrasjonen av de ubrukte postene til den sekundære - lagringsenheten, er det nødvendig å frigjøre den plassen de samme postene-opptar på disken. Dette oppnås effektivt ved å gjøre filen om til en spredt fil. Med andre ord, postene som har gjennomgått migrasjon erstattes av hull. Diskplassen som tidligere var opptatt av redundante poster er dermed frigjort, siden hullene ikke tar opp diskplass. Ved å anta at posten med høyest offsetverdi ikke arkiveres, vil den logiske lengden av filen forbli uendret av denne operasjonen, men antallet bytes med faktiske data reduseres og gir rom for nye filer med data.

Den spredte filen kan opprettes på følgende måte. Anta at systemet har en filallokeirngstabell (FAT) hvor diskplass fordelaktig tildeles i blokker av 25 byte. Derfor vil 7 blokker være nødvendig for å gi plass til de 175 bytes filen var på 10. april 1995. Filen kan være fordelt på følgende måte:

Legg merke til at første innføring i tabellen lagres i katalogstrukturen. Hver blokk på disken har en innføring i tabellen som indikerer den blokken der neste del av filen kan finnes. F. eks. har annen blokk en innføring som lenker til blokk 3 hvor den delen av filen med en offset på 50 byte kan finnes. Den 7 blokken har bare en negativ innføring (-1) for å indikere at det er siste blokk som inneholder data for filen. I dette eksempelet er filen fordelaktig lagret i rekkefølge i blokkene 1 til 7, men i praksis kan blokkene like gjerne være tildelt i tilfeldig rekkefølge med mellomrom seg imellom.

Allokeringstabellen må justeres for å frigjøre diskplass brukt av de migrerte poster, med andre ord byte 0 til 74 og byte 100 til 149 av filen må slettes. Det første området opptas av blokk 1, 2 og 3, og den andre av blokk 5 og 6. Når data i disse blokkene slettes, justeres de gjenstående innføringer for filen slik at et kjede av innføringer beholdes. Den modifiserte filallokeringstabellen vil derfor være: Blokkene 1, 2, 3, 5 og 6 har alle en nullinnføring (0) for å indikere at disse nå er uten data. Fra den modifiserte filallokeringstabellen, kan operativsystemet raskt bestemme at den første tildelte blokk for filen er blokk 4 som inneholder data som begynner ved logisk offset 75 og at den neste (og siste) blokk med fildata er lagret i blokk 7 og inneholder data som begynner ved logisk offset 150. Det bør legges merke til at noen operativsystemer ikke lagrer logisk offset for første tildelte blokk, som derfor, i slike systemer, ikke kan frigjøres.

Den nøyaktige måte selve slettingen gjennomføres på er ikke viktig. Det som er viktig er at plassen opptatt av de migrerte blokkene gjøres tilgjengelig på harddisken, dvs. at de frigjøres for bruk.

I eksempelet over, for å gjøre forklaringen enkel, har blokkstørrelse og lese-/skriveforespørslene alle vært antatt å være 25 byte og videre har det vært antatt at forespørslene alle opptrådte nøyaktig ved blokkgrenser. I praksis er den tildelte blokkstørrelse typisk et multippel av 512 byte, og posisjon og lengde på lese-/skriveforespørselen vil variere vesentlig. Siden bare hele blokker kan frigjøres (slettes), må systemet implementeres slik at bare dataområder som representerer hele blokker migreres og frigjøres. Siden store filer typisk opptar mange tusen blokker, er denne reduksjonen i effektivitet sjelden signifikant.

Trinnene over illustreres i flytskjemaet i figur 5. Trinn 40 indikerer starten på en sikkerhetskopieirngsoperasjon. Først identifiseres den etterspurte filen, trinn 42. Deretter slås det opp i tilleggsdatabasen, trinn 44, for å skille ut de blokkene som har vært aksessert siden en spesifisert dato fra de som ikke har vært aksessert. I trinn 46 identifiseres de blokkene som ikke har vært aksessert siden den spesifiserte dato. Nå er det mulig at de ikke-aksesserte blokkene allerede har blitt sikkerhetskopiert som del av den vanlige rutinesikkerhetskopiering. Typisk vil de ha blitt sikkerhetskopiert mer enn én gang. Derfor er det ikke nødvendig å migrere dem eller sikkerhetskopiere dem igjen. Derimot er det nødvendig å migrere de blokker hvor tilstrekkelige sikkerhetskopier ikke allerede eksisterer, til sekundært lager. Disse kan identifiseres ved å merke dem. Hvorvidt det er blokkene som skal migreres som merkes eller de som ikke skal migreres er uvesentlig, så lenge de skilles fra hverandre skikkelig. I avgjørelsestrinn 48 gjøres derfor en bestemmelse om hvorvidt tilstrekkelige (f. eks. 3) sikkerhetskopier allerede eksisterer. Hvis ikke vil merkede blokker i trinn 50 sikkerhetskopieres eller migreres. I trinn 52 frigjøres plassen okkupert av alle de ikke-aksesserte blokker ved at filallokeringstabellen (FAT) endres slik at filen konverteres til en spredt fil. Hvis filen allerede er en spredt fil så tilføyes nye hull. Rutinene er derved fullført, trinn 54.

Det siste som må gjøres er å overvåke senere forsøk på å lese fra filen for å bestemme om forespørslene forsøker å lese migrerte data. Hvis intet gjøres for å oppfange leseforespørselen vil operativsystemet kunne returnere enten null data eller gi en feilmelding dersom et forsøk gjøres på å lese fra et hull i en spredt fil. Ved å oppfange en forespørsel om å lese migrerte data kan de nødvendige signaler genereres for å de-migrere den etterspurte informasjon automatisk. Dersom individuelle forespørsler er små, vil tiden det tar å de-migrere data være kort sammenlignet med å de-migrere en hel fil, siden bare data som faktisk trengs vil bli gjenopprettet.

Denne operasjonen er illustrert i figur 6. Trinn 60 indikerer begynnelsen på en leseaksess. Filen identifiseres, trinn 62, og start-offset og leselengde bestemmes i trinn 64, som i figur 3. Deretter går operasjonen til avgjørelsestrinn 66 som sjekker fiiallokeringstabellen (FAT) for å bestemme hvorvidt leseforespørselen er en forespørsel om å lese data i noen blokk eller blokker som har blitt migrert ved bruk av rutinen i figur 5. Dersom svaret på dette spørsmålet er nei, går operasjonen videre til trinn 70, 72 og 74 som tilsvarer henholdsvis trinn 26, 28 og 30 i figur 3. Dersom svaret på spørsmålet i trinn 66 er ja derimot, vil de nødvendige data først de-migreres i trinn 68, før operasjonen går videre til trinn 70, 72 og 74 som tidligere. Det er ikke nødvendig å de-migrere hele blokken, og generelt vil bare den posten eller de postene som er nødvendige bli de-migrert. Disse kan falle innenfor en blokk eller strekke seg over to eller flere blokker.

Rutinene i figur 3 og 6 forutsetter at diskaksess kan oppfanges. Hvordan dette oppnås vil beskrives under henvisning til figurene 7 og 8. Hver gang et program ønsker aksess til en fil kaller den opp en standard rutine som skriver data til disken. Denne rutinen, som i operativsystemet DOS er kjent som Interrupt 21 hex funksjon (INT21h), er en integrert del av operativsystemet. Disklesing er INT21h funksjon 3Fh, og diskskriving er INT21h funksjon 40h. Handlingen som utføres av rutinen er avhengig av parametrene som gis til rutinen ved oppstart. Denne rutinen vises i figur 7 som INT21h og danner en del av operativsystemet i et systemminnekart, hvor inngangspunktet i INT21h vises med en pil. For å gjennomføre en foretrukket metode i henhold til oppfinnelsen, legges ytterligere programkoder til på grensesnittnivået i operativsystemet som vist i figur 8.1 praksis i DOS-omgivelser, kan dette lastes inn i datamaskinen som en enhetsdriver ved hjelp av CONFIG. SYS-filen.

Den ytterligere programvare har den effekt at en instruksjon om å skrive data erstattes eller suppleres av et alternativt sett med instruksjoner.

Ved andre operativsystemer er det nødvendig å avbryte filskrivingsfunksjonen på en tilsvarende måte. En dyktig programmerer vil være i stand til å klargjøre de nødvendige rutiner ved å følge beskrivelsen over som angår DOS-operativsystemet.

Mer generelt kan oppfinnelsen utføres i mange modifiserte metoder og andre metoder og systemer enn de som er beskrevet og illustrert.

Spesielt kan metoden og systemet kombineres med det delvise sikkerhetskopieringssystem beskrevet i min tidligere nevnte søknad 08/165, 382. Når dette gjøres kan tilleggsdatabasen brukes for å notere modifikasjoner av data slik den brukes i overensstemmelse med foreliggende oppfinnelse for å føre fortegnelse over aksess til data. Den eneste forskjellen er at det blir nødvendig å nedtegne i tilleggsdatabasen hvorvidt tilgangen var en lese-eller skriveaksess. Det delvise filsikkerhetskopieringssystem fra min tidligere søknad reagerer dermed på innføringer som angår skrivetilgang til tilleggsdatabasen, mens det delvise fil-HSM-system fra denne søknad tar vare på både lese og skrivetilganger.

I en annen modifikasjon utvides systemet ved i praksis å øke inaktivitetsterskelen til tilleggsdatabasens levetid. Det vil si at i figur 5 modifiseres trinn 44 slik at istedenfor å skille ut blokker som har eller ikke har blitt aksessert siden en spesifisert dato, skilles det mellom blokker som har eller ikke har blitt aksessert i det hele tatt, dvs. siden tilleggsdatabasen først ble opprettet eller fylt. I dette tilfellet trenger tilleggsdatabasen ikke lenger å registrere datoen eller dato/tid for hver tilgang.

Det kan være tilfeller der det ikke er ønskelig å migrere enkelte deler av filen selv om de ikke har vært aksessert. Dette kan f. eks angå første og muligens siste blokk i hver fil.

Til slutt dersom oppfinnelsen skal gjennomføres i forhold til et fullstendig nytt operativsystem, kan tilleggsdatabasen i prinsippet kombineres med filallokeringstabellen (FAT). Det vil imidlertid vanligvis være foretrukket å holde de to atskilt.

Claims (16)

1. Datamaskinsystem som sørger for en hierarkisk lagringsstyring, hvor datamaskinsystemet omfatter et direktetilgangsminne (14), en mikroprosessor (12), primære masselagringsmidler (16), sekundære arkivlagringsmidler (18) og innretning for å arkivere data lagret i et datamaskinsystem, hvor nevnte innretning omfatter: (a) midler operative under normal bruk omfattende: midler for å levere instruksjoner lagret i direktetilgangsminnet (14) til mikroprosessoren (12) for å sørge for at mikroprosessoren (12) søker etter data som er lagret i de primære masselagringsmidlene (16) ved å generere i det minste en leseforespørsel; første identifiserende midler (22) for å identifisere en fil som det trengs tilgang til, hvor filen består av fildeler; andre identifiserende midler (24) for å identifisere fildeler i filen som det trengs tilgang til; tilgangsmidler (28) for å få tilgang til fildelene inklusiv midler for å sjekke en filallokeringstabell som definerer lokasjonen til fildelene på den primære masselagringsenheten (16) for å bestemme om fildeler er på den primære masselagringsenheten (16), og i så fall lokasjonene til slike fildeler; og byggeinnretninger (26) for å bygge en database som identifiserer fildelslokasjonene som det gjøres tilgang til, hvor databasen ikke inneholder selve fildelen; (b) midler som er operative for arkivering, omfattende av: midler for å levere instruksjoner lagret i direktetilgangsminnet (14) til mikroprosessoren (12) for å sørge for at mikroprosessoren (12) arkiverer valgte data lagret i de primære masselagringsmidlene (16) på de sekundære arkivlagringsmidlene (18) for å frigjøre plass på de primære masselagringsmidlene (16); tredje identifiserende innretninger (42, 44) for å identifisere, fra databasen, lokasjoner til fildeler som har blitt aksessert; arkiverende midler (46-50) for å arkivere fra de primære masselagringsmidlene (16), til de sekundære arkiverende lagringsmidlene (18), i det minste noen filedeler som ikke har blitt aksessert; og slettemidler (52) for å frigi, på de primære masselagringsmidlene (16), plassen som blir okkupert av de fildelene som ikke har blitt aksessert, men som har blitt arkivert av de arkiverende midlene, og samtidig opprettholde fildeler som har blitt aksessert på de primære masselagringsmidlene (16); og (c) midler som er operative for uthenting, omfattende av: midler for å tilveiebringe instruksjoner lagret i direktetilgangsminnet (14) til mikroprosessoren (12) for å sørge for at mikroprosessoren (12) henter ut valgte data som er arkivert på de sekundære arkiverende lagringsmidlene (18) til de primære masselagringsmidlene (16) for tilgang; og midler (68, 70) som responderer på tilgangsmidlene som bestemmer at ønskede fildeler ikke er på det primære masselagringsmiddelet (16), for å hente ut de ønskede fildelene fra det sekundære arkiverende lagringsmiddelet (18) til det primære masselagringsmiddelet (16) for tilgang.

2. Datamaskinsystem i henhold til krav 1, hvor fildelene er blokker som korresponderer til de elementære blokkene som er identifisert i filallokeringstabellen.

3. Datamaskinsystem i henhold til krav 1 eller 2, hvor databasen videre definerer om tilgangen er skrive- eller lesetilgang.

4. Datamaskinsystem i henhold til krav 1, 2 eller 3, hvor byggeinnretningen (26) identifiserer fildelene som skal aksesseres, og dato eller dato/tid hvor aksessering er gjort.

5. Datamaskinsystem i henhold til krav 4, hvor de tredje identifiserende innretningene (42,44) omfatter midler (44) for å identifisere, fra databasen, fildeler som har vært aksessert siden en spesifikk dato og fildeler som ikke har blitt aksessert siden den spesifikke datoen; de arkiverende midlene (46-50) omfatter midler for å arkivere til de sekundære arkivmasselagirngs-midlene (18), minst noen fildeler som ikke har vært aksessert siden den spesifiserte datoen; og slettemidlene (52) omfatter midler for å frigi, på de primære masselagringsmidlene (16), plassen som er okkupert av de fildelene som ikke har blitt aksessert siden den spesifiserte datoen, men som har blitt arkivert av de arkiverende midlene, og samtidig opprettholde fildeler som har blitt aksessert siden den spesifiserte datoen på de primære masselagrings-midlene (16).

6. Datamaskinsystem i henhold til krav 5, hvor de arkiverende midler (46-50) og slettemidlene (52) omfatter midler (48) for å arkivere og slette de fildelene som ikke har blitt aksessert siden en spesifikk dato, og som det allerede har blitt tatt sikkerhetskopi av et forhåndsbestemt antall ganger.

7. Datamaskinsystem i henhold til et hvilket som helst av de foregående kravene, hvor slettemidlene (52) omfatter midler for å endre filallokeringstabellen.

8. Datamaskinsystem i henhold til ethvert av de foregående kravene, hvor byggeinnretningen (26) konsoliderer databasen for å fjerne overflødig informasjon.

9. Fremgangsmåte for å aksessere data lagret i et datamaskinsystem som sørger for en hierarkisk lagringsstyring, hvor datamaskinsystemet innbefatter et direktetilgangsminne, en mikroprosessor, primære masselagringsmidler, sekundære arkivlagirngsmidler og innretning for å arkivere data lagret i et datamaskinsystem, hvor metoden består av trinnene: (a) i vanlig bruk: levere instruksjoner lagret i direktetilgangsminnet til mikroprosessoren for å forårsake at mikroprosessoren søker å aksessere data lagret i de primære masselagringsmidlene ved å generere minst en leseforespørsel; identifisere en fil som det trengs tilgang til, hvor filen er satt sammen av fildeler; identifisere fildeler i filen som det trengs tilgang til. aksessere fildelene, hvor aksesseringstrinnet inkluderer å sjekke en filallokeirngstabell som definerer lokasjonen til fildeler på de primære masselagringsmidlene for å bestemme om fildelene er på de primære masselagringsmidlene og i så fall lokasjonene til slike fildeler; og bygging av en database som identifiserer lokasjonene til fildeler som det trengs tilgang til, hvor databasen ikke inneholder selve tildelen; (b) når det arkiveres: levere instruksjoner lagret i direktetilgangsminne til en mikroprosessor for å forårsake at mikroprosessoren arkiverer valgte data lagret i de primære masselagringsmidlene på sekundære arkivlagirngsmidler for å frigjøre plass på de primære masselagringsmidlene; identifisere, fra databasen, lokasjonene til fildeler som har blitt aksessert; arkivere fra de primære masselagringsmidlene til de sekundære arkivlagringsmidlene i det minste noen fildeler som ikke har blitt aksessert; og frigjøre, på de primære masselagringsmidlene, plassen som har blitt okkupert av de fildelene som ikke har blitt aksessert, men som har blitt arkivert av arkiverende midler, og samtidig beholde, på de primære masselagringsmidlene, fildeler som har blitt aksessert; og (c) for uthenting: levere instruksjoner lagret i direktetilgangsminne til mikroprosessoren for å forårsake at mikroprosessoren henter valgte data som er arkivert på sekundære arkivlagringsmidler til de primære masselagringsmidlene for tilgang; og når det er bestemt at fildelene ikke er på de primære masselagringsmidlene, hente de ønskede fildelene fra de sekundære arkivlagringsmidlene til de primære masselagringsmidlene for tilgang.

10. Fremgangsmåte i henhold til krav 9, hvor fildelene er blokker som korresponderer med de elementære blokkene som er definert i filallokeringstabellen.

11. Fremgangsmåte i henhold til krav 9 eller 10, hvor databasen videre definerer om tilgangen er en skrive- eller lesetilgang.

12. Fremgangsmåte i henhold til krav 9, 10 eller 11, hvor trinnene med bygging identifiserer fildelene som det skal gis tilgang til, og dato eller dato/tid hvor tilgang er gjort.

13. Fremgangsmåte i henhold til krav 12, hvor trinnet med arkivering av identifisering av hvilke fildeler som har blitt aksessert består av å identifisere, fra databasen, fildeler som har vært aksessert siden en spesifisert dato og fildeler som ~ ikke har blitt aksessert siden en spesifisert dato; hvor det arkiverende trinnet består av arkivering til det sekundære arkivlagringsmiddelet i det minste noen fildeler som ikke har blitt aksessert siden en spesifisert dato; og det frigjørende steget består av å frigjøre, på det primære masselagringsmiddelet, plassen som er okkupert av de fildelene som ikke er aksessert siden en spesifisert dato, men som har blitt arkivert av de arkiverende midlene, og samtidig beholde, på de primære masselagringsmidlene, fildeler som har vært aksessert siden en spesifisert dato.

14. Fremgangsmåte i henhold til krav 13, hvor det arkiverende trinnet og det frigjørende trinnet består av å arkivere og slette de fildelene som ikke har blitt aksessert siden en spesifisert dato og som det allerede har blitt tatt sikkerhetskopi av et forhåndsbestemt antall ganger.

15. Fremgangsmåte i henhold til et hvilket som helst av kravene 9 til 14, hvor det frigjørende trinnet består av å endre filallokeringstabellen.

16. Fremgangsmåte i henhold til et hvilket som helst av kravene 9 til 15, hvor byggetrinnet består av å konsolidere databasen til å fjerne overflødig informasjon.