close

Hierarkisk filsystem

Gå til navigation Gå til søg
HFS
Udvikler Apple computer
Fulde navn Hierarkisk filsystem
Understøttede operativsystemer Mac OS , Mac OS X
Introduktion 17. september 1985 ( System 2.1 )
partitions-id Apple_HFS (Apple Partition Map)
0xAF ( MBR )
strukturer
mappeindhold B-træ*
filplacering Bitmap
dårlige blokke B-træ*
Grænser
Maksimal fildimension 2  GB ( 2 × 1024 3 bytes )
Maksimalt antal filer 65535
Maksimal filnavnstørrelse 31 tegn
Maksimal volumenstørrelse 2 TB  ( 2 × 1024 4 bytes )
Tegn tilladt i filnavne Alle 8-bit tegn undtagen kolon ":". Brugen af ​​nul-tegn og ikke-udskrivbare tegn frarådes.
Egenskab
registrerede datoer Oprettelse, ændring, backup
Datointerval 1. januar 1904 - 6. februar 2040
dato beslutning 1s
gafler 2 (data og ressourcer)
egenskaber Farve (3 bit, resten af ​​attributter 1 bit), lås, brugerdefineret ikon, bundt, usynlig, alias, system, brevpapir, indledt, ingen INIT-ressourcer, delt, skrivebord
Filadgangstilladelser AppleShare
gennemsigtig kompression Ja (tredjepart), Stacker
gennemsigtig kryptering Nix

Hierarchical File System eller Hierarchical File System (HFS) er et filsystem udviklet af Apple Inc. til brug på computere, der kører Mac OS . Oprindeligt designet til at blive brugt på disketter og harddiske , kan den også findes på skrivebeskyttede enheder såsom cd-rom'er . HFS er navnet, der bruges af udviklere, men i brugerdokumentation omtales formatet som Mac Os Standard for at adskille det fra dets efterfølger HFS+ , som kaldes Mac Os Extended.

Historie

HFS blev introduceret af Apple i september 1985 for at erstatte Macintosh File System ( MFS ), det originale filsystem, som blev introduceret et år før Macintosh Computers . Udviklet af Patrick Dirks og Bill Bruffey delte HFS en række designfunktioner med MFS, som ikke var tilgængelige i andre filsystemer på den tid (såsom DOS 's FAT ). Filer kunne have flere gafler (normalt data og en ressourcegaffel ), hvilket gjorde det muligt at lagre programkode adskilt fra ressourcer såsom ikoner, der muligvis skal lokaliseres. Filer blev henvist til med unikke ID'er, og filnavne kunne være 255 tegn lange (selvom Finder kun understøttede maksimalt 63 tegn).

Mens MFS var optimeret til brug på små, langsomme lagermedier som floppydiske, blev HFS introduceret for at overvinde nogle af de ydeevneproblemer, der fulgte med introduktionen af ​​store lagermedier som harddiske. Den største bekymring var den tid, det tog at vise indholdet af en mappe. Under MFS blev hele listen over fil- og mappeoplysninger gemt i en enkelt fil, som systemet skulle slå op for at bygge en liste over filerne gemt i en bestemt mappe. Dette fungerede fint med et system med et par hundrede kilobyte lagerplads og måske hundrede filer, men da systemerne voksede med megabyte og tusindvis af filer, faldt ydeevnen hurtigt.

Løsningen var at erstatte MFS -biblioteksstrukturen med en mere egnet til større filsystemer. HFS erstattede den flade tabelstruktur med Catalog File, som bruger en B*-træstruktur, der kan søges meget hurtigt, uanset dens størrelse.

Selvom HFS er et proprietært Ben-filsystemformat, er det veldokumenteret, så der er løsninger til at få adgang til HFS-formaterede diske fra de fleste moderne operativsystemer. I 1998 introducerede Apple HFS+ for at afhjælpe ineffektiviteten af ​​diskpladsallokering i HFS og tilføje andre forbedringer. HFS understøttes stadig af nuværende versioner af Mac OS , men fra Mac OS X kan en HFS-diskenhed ikke bruges til opstart.

Design

Organisering af et HFS-filsystem.

Det hierarkiske filsystem opdeler et volumen i logiske blokke på 512 bytes. Disse logiske blokke er grupperet sammen i allokeringsblokke, der kan indeholde en eller flere logiske blokke afhængigt af volumenets samlede størrelse. HFS bruger en 16-bit adresseværdi til allokeringsblokke, hvilket begrænser antallet af allokeringsblokke til 65.536.

Der er fem strukturer, der udgør en HFS-volumen:

  1. De logiske blokke 0 og 1 i volumen er opstartsblokkene, som indeholder systemstartinformationen. For eksempel navnet på systemet og shell-filen (normalt Finder), der indlæses ved opstart.
  2. Logisk blok 2 indeholder MDB-biblioteket (Master Directory Block). Dette definerer en lang række data om selve volumen, for eksempel datoen og tidsstemplet for, hvornår volumen blev oprettet, placeringen af ​​andre volumenstrukturer, såsom bitmapvolumen, eller størrelsen af ​​logiske strukturer såsom tildelingsblokke. Der er også en duplikat af MDB kaldet den alternative MDB placeret i den modsatte ende af volumen i den næstsidste logiske blok. Dette er primært beregnet til brug af diskværktøj og opdateres kun, når katalogfilen eller udvidelsesoverløbsfilen øges i størrelse.
  3. Logisk blok 3 er startblokken for bitmapvolumenet (Volume Bitmap), som holder styr på hvilke allokeringsblokke der er i brug, og hvilke der er ledige. Hver allokeringsblok på volumen er repræsenteret af en bit i kortet: hvis bit er tændt, er blokken i brug; hvis den er deaktiveret, er blokken gratis at bruge. Da Volume Bitmap skal have én bit for at repræsentere hver allokeringsblok, bestemmes størrelsen af ​​volumen.
  4. Extent Overflow-filen er et B*-træ, der indeholder udvidelser, der registrerer, hvilke allokeringsblokke, der er tildelt hvilke filer, når først de tre indledende udvidelser af katalogfilen er brugt. Senere versioner tilføjer også muligheden for Extent Overflow File til at logge dårlige blokke, for at forhindre filsystemet i at forsøge at allokere en dårlig blok til en fil.
  5. Katalogfilen er et andet B*-træ, der indeholder poster for alle filer og mapper, der er gemt på diskenheden. Gemmer fire typer poster. Hver fil består af en File Thread Record og en File Record, mens hver mappe består af en Directory Thread Record og en Directory Record. Filerne og mapperne i Katalogfilen er identificeret med et unikt CNID (Catalog Node ID).
    • En File Thread Record gemmer kun navnet på filen og CNID for dens overordnede mappe.
    • En filpost gemmer en række metadata om filen, herunder dens CNID, størrelsen af ​​filen, tre tidsstempler (hvornår filen blev oprettet, sidst ændret, og hvornår den sidst blev sikkerhedskopieret), den første udvidede fil med dataene, og ressourcerne og pointerne til de første data i filen og udvidede ressourceposter i Extent Overflow-filen. Filposten gemmer også to 16-byte felter, der bruges af Finder til at gemme attributter om filen, herunder ting som dens oprettelseskode, typen af ​​kode, om filvinduet skal vises, og dets placering uden vinduet.
    • En Directory Thread Record gemmer kun biblioteksnavnet og CNID for dets overordnede bibliotek.
    • En Directory Record gemmer data såsom antallet af filer gemt i mappen, CNID for mappen, tre tidsstempler (tidspunkt for oprettelse, sidste ændring og sidste backup). Ligesom File Record gemmer den også to 16-byte felter til brug for Finder. Disse elementer er gemt som bredden og højden og x- og y-koordinaterne for vinduet, der bruges til at vise indholdet af mappen, vinduets visningstilstand (ikonvisning, listevisning osv.) og positionen af ​​vinduets rullepanel .

Problemer

Katalogfilen, som gemmer alle fil- og biblioteksposter i en enkelt datastruktur, er et ydelsesproblem, når systemet tillader multitasking, kun ét program kan skrive til denne struktur ad gangen, det betyder, at mange programmer skal stå i kø til kl. det første program frigiver systemet. Det er også et alvorligt pålidelighedsproblem at beskadige denne fil, da det kan ødelægge hele filsystemet. Dette er i modsætning til andre filsystemer, der gemmer fil- og biblioteksposter i separate strukturer (såsom Microsofts FAT-filsystem eller Unix File System, UFS), hvor det at have strukturer fordelt over disken betyder, at beskadigelse af en mappe ikke det er generelt fatalt og muligvis kan data rekonstrueres med data fra de ubeskadigede dele.

Desuden resulterer grænsen på 65.535 tildelingsblok i filer med en "minimum" størrelse svarende til 1/65.535 af diskstørrelsen. Derfor kan enhver volumen, uanset størrelsen, kun gemme maksimalt 65.535 filer. Enhver fil kan dog tildeles mere plads, end den faktisk har brug for, op til størrelsen af ​​allokeringsblokken. Når diske var små, betød det ikke meget, fordi størrelsen af ​​de enkelte allokeringsblokke var meget lille, men da diske begyndte at overgå 1GB-mærket, kan den mindste mængde plads en fil (en enkelt blok) optage. allokering) blev for stor og spildte betydelige mængder diskplads. For eksempel på en 1 GB disk er allokeringsblokstørrelsen under HFS 16 KB, så en 1 Byte fil ville optage 16 KB diskplads. Dette problem var mindre af et problem for brugere, der havde store filer på en mindre volumen, fordi de fylder meget mindre, end hvis de lå på en stor partition. Det samme problem findes i FAT16-filsystemet.

Eksterne links

Hentet fra « https://es.wikipedia.org/w/index.php?title=Hierarchical_File_System&oldid=132289711 »