Hierarchický systém souborů - Hierarchical File System

Nesmí být zaměňována s Filesystem Hierarchy Standard nebo Hierarchical File System (IBM MVS) .
HFS
Vývojáři Počítač Apple
Celé jméno Hierarchický systém souborů
Představený 17. září 1985 ; Před 35 lety se systémem 2.1 ( 1985-09-17 )
Identifikátor oddílu Apple_HFS( Apple Partition Map )
0xAF( MBR ) HFS a HFS +
Struktury
Obsah adresáře B-strom
Přidělení souborů Rastrový obrázek
Špatné bloky B-strom
Limity
Max. velikost svazku 2  TB ( 2 × 1024 4 bajty )
Max. velikost souboru 2  GB ( 2 × 1024 3 bajty )
Max. počet souborů 65535
Max. délka názvu souboru 31 znaků
Povolené znaky v názvech souborů Všechny 8bitové hodnoty kromě dvojtečky ":". Odradit null a netiskne.
Funkce
Zaznamenaná data Vytváření, úpravy, zálohování
Časové období 1. ledna 1904 - 6. února 2040
Rozlišení data 1 s
Vidlice Pouze 2 (data a zdroj)
Atributy Barva (3 bity, všechny ostatní příznaky 1 bit), uzamčeno, vlastní ikona, svazek, neviditelný, alias, systém, papírnictví, inited, žádné zdroje INIT, sdílené, desktop
Oprávnění systému souborů AppleShare
Transparentní komprese Ano (třetí strana), stohovač
Transparentní šifrování Ne
jiný
Podporované operační systémy Klasický Mac OS , macOS , Linux , Microsoft Windows (prostřednictvím ovladačů MacDrive nebo Boot Camp IFS )

Hierarchical File System ( HFS ) je proprietární souborový systém vyvinutý společností Apple Inc. pro použití v počítačových systémech se systémem Mac OS . Původně navržen pro použití na disketách a pevných discích , lze jej také najít na médiích jen pro čtení, jako jsou CD-ROM . HFS se také označuje jako Mac OS Standard (nebo „HFS Standard“), zatímco jeho nástupce, HFS Plus , se také nazývá Mac OS Extended (nebo „HFS Extended“).

Se zavedením systému Mac OS X 10.6 společnost Apple upustila od podpory formátování nebo zápisu disků a obrázků HFS , které zůstávají podporovány jako svazky jen pro čtení . Počínaje macOS 10.15 již nelze disky HFS číst.

Dějiny

Společnost Apple představila HFS v září 1985, konkrétně na podporu prvního pevného disku Apple pro Macintosh, který nahradil souborový systém Macintosh (MFS), původní souborový systém, který byl zaveden o rok a půl dříve s prvním počítačem Macintosh . HFS těžce čerpal z prvního hierarchického operačního systému ( SOS ) společnosti Apple pro nefunkční Apple III , který také sloužil jako základ pro hierarchické souborové systémy na Apple IIe a Apple Lisa . HFS vyvinuli Patrick Dirks a Bill Bruffey. To sdílí celou řadu konstrukčních prvků s MFS, které nebyly k dispozici v dalších souborových systémů té doby (například DOS ‚s FAT ). Soubory by mohly mít více vidlic (obvykle datovou a vidličku prostředků ), což umožňovalo ukládat hlavní data souboru odděleně od prostředků, jako jsou ikony, které je třeba lokalizovat. Na soubory se odkazovalo spíše na jedinečné ID souborů než na názvy souborů a názvy souborů mohly mít délku 255 znaků (ačkoli Finder podporoval pouze maximálně 31 znaků).

MFS však byl optimalizován pro použití na velmi malých a pomalých médiích, konkrétně na disketách , takže byl zaveden HFS, aby překonal některé problémy s výkonem, které se objevily při zavedení větších médií, zejména pevných disků . Hlavním problémem byl čas potřebný k zobrazení obsahu složky. V rámci MFS byly všechny informace o výpisu souborů a adresářů uloženy v jediném souboru, který musel systém prohledat, aby vytvořil seznam souborů uložených v konkrétní složce. To fungovalo dobře se systémem s několika stovkami kilobajtů úložiště a možná stovkou souborů, ale jak systémy přerostly v megabajty a tisíce souborů, výkon se rychle snížil.

Řešením bylo nahradit adresářovou strukturu MFS jednou vhodnější pro větší souborové systémy. HFS nahradil strukturu ploché tabulky katalogovým souborem, který používá strukturu B-stromu , kterou lze prohledávat velmi rychle bez ohledu na velikost. HFS také přepracoval různé struktury, aby dokázal pojmout větší čísla, 16bitová celá čísla jsou téměř univerzálně nahrazena 32bitovými. Kupodivu jedním z mála míst, kde k této „změně velikosti“ nedošlo, byl samotný adresář souborů, který omezuje HFS na celkem 65 535 souborů na každém logickém disku.

Zatímco HFS je proprietární formát souborového systému, je dobře zdokumentovaný; k přístupu na disky ve formátu HFS z většiny moderních operačních systémů jsou obvykle k dispozici řešení .

Společnost Apple představila HFS z nutnosti s první nabídkou 20 MB pevného disku pro Macintosh v září 1985, kdy byla načtena do RAM z diskety MFS při spuštění pomocí souboru opravy („Hard Disk 20“). HFS však nebyl široce představen, dokud nebyl zahrnut do 128K ROM, který debutoval v Macintosh Plus v lednu 1986, spolu s větší disketovou jednotkou 800 KB pro Macintosh, který také používal HFS. Zavedení HFS bylo prvním pokrokem společnosti Apple, který zanechal počítačový model Macintosh: původní 128K Macintosh , který postrádal dostatek paměti pro načtení kódu HFS a byl okamžitě ukončen.

V roce 1998 společnost Apple představila HFS Plus, který řeší neefektivní alokaci místa na disku v HFS a přidává další vylepšení. HFS je aktuálními verzemi Mac OS stále podporováno, ale počínaje Mac OS X nelze svazek HFS použít pro bootování a počínaje Mac OS X 10.6 (Snow Leopard) jsou svazky HFS pouze pro čtení a nelze je vytvářet ani aktualizováno. V systému macOS Sierra (10.12) poznámky k vydání Apple uvádějí, že „Souborový systém HFS Standard již není podporován.“ Podpora HFS Standard jen pro čtení je však v Sierře stále přítomna a funguje stejně jako v předchozích verzích.

Design

Svazek úložiště je ze své podstaty rozdělen do logických bloků o velikosti 512 bajtů. Hierarchický systém souborů seskupuje tyto logické bloky do bloků přidělení , které mohou obsahovat jeden nebo více logických bloků, v závislosti na celkové velikosti svazku. HFS používá 16bitovou hodnotu k adresování alokačních bloků, čímž omezuje počet alokačních bloků na 65 535 (2 16 -1).

Svazek HFS tvoří pět struktur:

  1. Logické bloky 0 a 1 svazku jsou spouštěcí bloky , které obsahují informace o spuštění systému. Například názvy souborů System a Shell (obvykle Finder ), které se načtou při spuštění.
  2. Logický blok 2 obsahuje hlavní adresářový blok (aka MDB ). To definuje širokou škálu dat o samotném svazku, například razítka data a času, kdy byl svazek vytvořen, umístění dalších struktur svazku, jako je bitmapa svazku, nebo velikost logických struktur, jako jsou bloky přidělení. Existuje také duplikát MDB s názvem Alternate Master Directory Block (aka Alternate MDB ), který se nachází na opačném konci svazku ve druhém až posledním logickém bloku. Toto je určeno hlavně pro použití nástroji na disku a je aktualizováno, pouze pokud se zvětší velikost katalogového souboru nebo souboru přetečení obsahu.
  3. Logický blok 3 je počáteční blok Volume Bitmap , který sleduje, které bloky přidělení se používají a které jsou zdarma. Každý alokační blok na svazku je na mapě představován bitem: pokud je bit nastaven, blok se používá; pokud je to jasné, pak je blok volně použitelný. Vzhledem k tomu, že bitmapa svazku musí mít bit, který představuje každý blok přidělení, je její velikost určena velikostí samotného svazku.
  4. Soubor přetečení rozsahu je strom B, který obsahuje další rozsahy, které zaznamenávají, které bloky přidělení jsou přiřazeny ke kterým souborům, jakmile jsou vyčerpány počáteční tři rozsahy v souboru katalogu. Novější verze také přidaly schopnost souboru přetečení rozsahu ukládat rozsahy, které zaznamenávají špatné bloky, aby se zabránilo systému souborů ve snaze přidělit špatný blok souboru.
  5. Katalog Soubor je jiný B-tree , který obsahuje záznamy pro všechny soubory a adresáře uložené v objemu. Ukládá čtyři typy záznamů. Každý soubor se skládá ze záznamu podprocesu souboru a záznamu souboru, zatímco každý adresář se skládá ze záznamu podprocesu adresáře a záznamu adresáře. Soubory a adresáře v katalogovém souboru jsou umístěny podle jejich jedinečného ID uzlu katalogu (nebo CNID ).
    • A Soubor Thread záznamu ukládá pouze název souboru a CNID z nadřazeného adresáře.
    • Souboru záznamu uloží paletu metadata o souboru včetně jeho CNID, velikost souboru, tři časové značky (kdy byl soubor vytvořen, naposledy upravoval, naposledy zálohovány), první soubor rozsahů těchto dat a vidličky zdroje a odkazy k prvním záznamům o rozsahu dat a zdrojů v souboru v souboru přetečení rozsahu. Záznam souboru také ukládá dvě 16bajtová pole, která Finder používá k ukládání atributů o souboru, například kód jeho tvůrce , typový kód , okno, ve kterém by se měl soubor objevit, a jeho umístění v okně.
    • Directory Thread záznamu ukládá pouze název adresáře a CNID z nadřazeného adresáře.
    • Directory Record , která data ukládá jako počet souborů uložených v adresáři se CNID adresáře, tři časové značky (pokud byl vytvořen adresář, poslední upravené naposledy zálohovány). Stejně jako záznam souboru, záznam adresáře také ukládá dvě 16bajtová pole pro použití vyhledávačem. Ukládají věci, jako je šířka a výška a souřadnice x & y pro okno použité k zobrazení obsahu adresáře, režim zobrazení (zobrazení ikon, zobrazení seznamu atd.) Okna a poloha rolování okna bar.

Omezení

Katalogový soubor, který ukládá všechny záznamy souborů a adresářů do jediné datové struktury, má za následek problémy s výkonem, když systém umožňuje multitasking , protože do této struktury může zapisovat pouze jeden program najednou, což znamená, že mnoho programů může čekat ve frontě kvůli jednomu programu „hogging“ systému. Jedná se také o vážný problém se spolehlivostí, protože poškození tohoto souboru může zničit celý souborový systém. To kontrastuje s jinými systémy souborů, které ukládají záznamy souborů a adresářů v samostatných strukturách (například v systému souborů FAT systému DOS nebo v systému souborů Unix ), kde struktura rozdělená na disk znamená, že poškození jednoho adresáře je obecně nezávažné a data může být případně znovu vytvořeno s daty uchovávanými v nepoškozených částech.

Navíc limit 65 535 alokačních bloků vedl k tomu, že soubory měly velikost „minimální“ velikosti 1/65 535 velikosti disku. Jakýkoli daný svazek, bez ohledu na jeho velikost, tedy mohl uložit maximálně 65 535 souborů. Jakémukoli souboru by navíc bylo přiděleno více místa, než ve skutečnosti potřeboval, a to až do velikosti bloku přidělení. Když byly disky malé, nemělo to žádný důsledek, protože velikost jednotlivých bloků přidělení byla triviální, ale když se disky začaly přibližovat ke značce 1 GB, nejmenší množství místa, které mohl libovolný soubor zabírat (jeden blok přidělení), se stalo příliš velkým. , plýtvání významným množstvím místa na disku. Například na 1 GB disku je velikost alokačního bloku pod HFS 16 KB, takže i 1 bajtový soubor by na disku zabral 16 KB. Tato situace představovala menší problém pro uživatele, kteří mají velké soubory (například obrázky, databáze nebo zvuk), protože tyto větší soubory zbytečně ztrácely místo jako procento jejich velikosti souboru. Uživatelé s mnoha malými soubory by na druhé straně mohli kvůli velké velikosti bloku přidělení ztratit velké množství místa. Díky tomu bylo rozdělení disků na menší logické svazky pro uživatele počítačů Mac velmi lákavé, protože malé dokumenty uložené na menším svazku by zabíraly mnohem méně místa, než kdyby byly umístěny na velkém oddílu. Stejný problém existoval v systému souborů FAT16.

HFS uloží případ souboru, který je vytvořen nebo přejmenován, ale v provozu nerozlišuje velká a malá písmena.

Podle bombich.com již HFS není podporován v Catalině ani v budoucích vydáních pro macOS.

Viz také

Reference

externí odkazy