České vysoké učení technické v Praze Fakulta elektrotechnická Bakalářská práce Výukový systém UFS Petr Klimeš Vedoucí práce: Ing. Jan Trdlička, Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný, bakalářský Praha 2006
ii
Poděkování Rád bych tímto poděkoval bohu, přítelkyni a rodině, že mi umožnila pracovat nad danou problematikou. iii
iv
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 9.6.2006... v
vi
Abstract The work represents how data are stored on disk using Unix file system structure. It shows us how and where are these data stored on physical hard disk. In detail illustrate all hierarchic tree structure, what is I-node and which information carries about files. Result of UFS research is program showing playfully how data are stored on disk. Abstrakt Páce prezentuje problematiku ukládání dat v Unixovém souborovém systému. Ukazuje jak a kde jsou fyzicky data uložena na disku. Přibližuje a detailně vysvětluje hierarchickou stromovou strukturu, co to je I-uzel, jaké informace o souboru ukládá. Výsledkem celého studia problematiky je program resp. applet, který ukazuje a vysvětluje, jak jsou data v UFS souborovém systému uspořádána. vii
viii
Obsah Seznam ilustrací...xi Seznam tabulek...xiii 1 Úvod...1 1.1 Historie UFS...1 1.1.1 Systém V File System...1 1.1.2 BSD Fast File System...1 1.1.3 Unix File systém - UFS...1 2 Vnitřní reprezentace systému souborů...3 2.1 Systém souborů...3 2.1.1 Co je systém souborů...3 2.2 Klasický systém souborů v Unixu...3 2.2.1 Zaváděcí blok...4 2.2.2 Superblok...4 2.2.3 I-uzel...5 2.2.4 Datové bloky...7 2.3 Soubory v klasickém Unix systému souborů...8 2.3.1 Struktura běžného souboru...8 2.3.2 Adresář...9 2.4 Unixový systém souborů (UFS)...10 2.4.1 Zaváděcí blok...11 2.4.2 Superblok...11 2.4.3 Deskriptor skupiny válce cylinder group summary...13 2.4.4 Bitové mapy...15 2.5 Soubory v UFS...15 2.5.1 Struktura běžného souboru...15 2.5.2 Adresář...15 3 Analýza...17 3.1 Volba programovacího jazyka...17 3.1.1 Applet...17 3.2 Omezení appletu...17 3.2.1 Podepsání appletu digitálním certifikátem...18 3.2.2 Politika udělení grantu appletu...18 3.3 Cíl práce...18 3.3.1 Jádro systému...19 3.3.2 Grafické uživatelské prostředí...19 4 Realizace...21 4.1 Java...21 4.1.1 Balíček java.awt...21 4.1.2 Balíček javax.swing...21 4.1.3 GUI (Graphical User Interface)...21 4.2 Návrh struktury implementace...22 4.2.1 Třída jádra systému...22 4.3 Nároky na vybavení strojů a programů...23 4.3.1 Potřebné SW vybavení...23 4.3.2 Potřebné HW vybavení...24 4.4 Realizace uživatelského rozhraní...24 4.4.1 Unixový terminál...24 4.4.2 Grafické zobrazení uložení dat na disku...25 4.4.3 Nastavení výukového systému UFS...26 ix
5 Testování...29 5.1 White-box testování...29 5.2 Black-box testování...29 6 Závěr...31 7 Seznam použité literatury...33 A Seznam použitých zkratek...35 B UML diagramy...37 C Uživatelská příručka...41 D Obsah přiloženého CD...49 x
Seznam ilustrací Ilustrace 1: Schéma systému souborů S5...4 Ilustrace 2: Bitová mapa...4 Ilustrace 3: Struktura I-uzlu...6 Ilustrace 4: Adresace datových bloků...7 Ilustrace 5: Nalezení cesty /etc/passwd v UFS...9 Ilustrace 6: Skupina válců (cylinder groups)...11 Ilustrace 7: Fyzická geometrie disku č.1...12 Ilustrace 8: Fyzická geometrie disku č.2...13 Ilustrace 9: Struktura deskriptoru skupiny válce...14 Ilustrace 10: Struktura adresáře v UFS2...16 Ilustrace 11: UML diagram třídy First...37 Ilustrace 12: UML diagram tříd Data, Inode, Dir...38 Ilustrace 13: UML diagram třídy Settings...38 Ilustrace 14: UML diagram metod třídy Data...39 Ilustrace 15: UML diagram třídy PlatnoBitMaps...40 Ilustrace 16: Uživatelská příručka - zobrazení ověřovacího certifikátu...41 Ilustrace 17: Uživatelská příručka - úvodní obrazovka...42 Ilustrace 18: Uživatelská příručka - příkazy shellu...43 Ilustrace 19: Uživatelská příručka - nastavení systému...43 Ilustrace 20: Uživatelská příručka - dialogové okno...44 Ilustrace 21: Uživatelská příručka - grafický výstup - úvodní legenda...44 Ilustrace 22: Uživatelská příručka - grafický výstup...45 Ilustrace 23: Uživatelská příručka - grafický výstup - bitové mapy...46 Ilustrace 24: Uživatelská příručka - grafický výstup - I-uzly...46 Ilustrace 25: Uživatelská příručka - grafický výstup - datové bloky...47 Ilustrace 26: Uživatelská příručka - grafický výstup - DB zdroj...47 xi
xii
Seznam tabulek Tabulka 1: Struktura adresáře v S5...10 Tabulka 2: Struktura adresáře v UFS...10 xiii
xiv
KAPITOLA 1 ÚVOD 1 1 Úvod Výukový systém UFS (Unix File System) prezentuje datovou strukturu souborového systému v Unixu. Ukazuje a hlavně se snaží podrobně vysvětlit celou problematiku rozvržení a uložení dat na disku. Pomocí výukového systému UFS má uživatel možnost zadávat do zobrazeného terminálu příkazy tak, jak je zná z Unixu. Například kopírování, mazání souborů a adresářů. Při každé operaci si uživatel může výsledné změny ověřit v grafické části. Znamená to, že při založení adresáře se lze přesvědčit o tom, jaké číslo I-uzlu se danému adresáři přidělilo a kolik zabírá místa na disku. 1.1 Historie UFS Unix File Systému předcházel tzv. S5 systém souborů a BSD Fast File System. 1.1.1 Systém V File System Systém souborů S5 vznikl v roce 1978. Byla to první univerzální implementace souborového sytému. Měla jednoduchý návrh, takový jaký je uveden v ilustraci 1 na str.4 tj. boot blok, super blok, tabulka I-uzlů, datové bloky. Superblok byl jenom jeden, dále obsahoval jenom jednu tabulku diskových I-uzlů a jednu oblast datových bloků. Přidělování diskových I-uzlů je náhodné, tj. I-uzly souborů téhož adresáře nejsou nijak seskupeny. Přidělování diskových bloků je tzv. suboptimální, tj. jenom při vytvoření souborového systému v diskové oblasti je seznam volných bloků konfigurován rotačně po sobě. 1.1.2 BSD Fast File System S5 pracovala dobře pro malé disky, pro které byl vlastně vyvinut. Technologie se s časem posunuly o hodný kus dál, disky se zvětšovaly, a pohyb hlav mezi hlavičkou souboru I-uzly ze začátku disku a daty z jiné části disku se stával zdlouhavým a nežádoucím [1]. V roce 1984 vydali pánové Marshall Kirk McKusick, William N. Joy, Samuel J. Leffler and Robert S. Fabry nový souborový systém pod názvem Fast File System, který se začal označovat jako Berkeley Fast File System nebo též BSD Fast File System, zkráceně FFS. Měl naprosto stejnou funkcionalitu v porovnání s S5. Hlavní přínos byl v rozvržení disku. Kromě rozdělení disku na oblasti, které obsahují souborové systémy, rozděluje BSD oblast dále na skupiny malého počtu válců (cylinder group), které obsahují bloky se souvisejícími I-uzly a datovými bloky. Bloky souboru jsou uloženy v diskových blocích, kromě posledního bloku, který může obsahovat jeden nebo více po sobě následujících fragmentů. 1.1.3 Unix File systém - UFS Některé komerční distribuce Unixu jako SunOS, HP-UX a Digital UNIX adoptovali UFS a zavedli jej do svých distribucí. Tato verze je označována
2 KAPITOLA 1 ÚVOD jako UFS1. První verze tzv. UFS1 vychází z původní koncepce BSD FFS. Novější UFS2 nepřináší žádné převratné změny oproti svému předchůdci, hlavním přínosem je rozšíření maximální velikosti disku, na který může být nainstalována. Struktura I-uzlů se moc nezměnila došlo k rozšíření ukazatelů na datové bloky z 32bitů na 64bitů, což umožňuje nasazení UFS2 na disky větší jak 1TB. Ve verzi UFS2 se zvětšila maximální velikost délky názvu souborů a adresářů na 256 znaků. Díky tomu, že není nikde definován standard UFS, nemají některé Linuxové distribuce plnou podporu tohoto systému souborů, dokonce názvosloví ohledně USF se různí. Rozvětvení UFS na dvě větve UFS1 a UFS2 došlo k jakémusi ustálení v názvosloví a to tak, že pro UFS se vžilo označovat větev UFS2, výjimečně UFS1. A označení FFS pro všechny starší verze tj. S5, FFS a UFS1. Protože není nikde definován standard, může se uživatel v literatuře setkat s označení UFS pro všechny verze souborových systémů, které byly zmíněné výše.
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 3 2 Vnitřní reprezentace systému souborů 2.1 Systém souborů Data je možné ukládat na permanentní paměťová média, obvykle na disky. Disková paměťová média je možné logicky rozdělit na několik oblastí tzv. partitions. Každý disk obsahuje minimálně jednu partition a obsah každé partition popisuje jeden systém souborů. Systém souborů je organizován jako strom s jedním kořenovým uzlem, nazvaným kořen, anglicky root, značeno /. Každý nelistový uzel struktury stromu je adresář a soubory jsou reprezentovány nejnižší položkou ve stromové struktuře tj. listy. Tento strom je jen jeden způsob, jak věci navenek vypadají, ve skutečnosti to však není způsob, jak jsou data na disku uložena. Je dobré vědět, že se jedná o databázi tvořenou jedním souborem, který se nazývá systém souborů, anglicky file system (FS), ten obsahuje řadu ukazatelů na data a na vlastní data souborů. 2.1.1 Co je systém souborů Systém souborů by se nejjednodušším způsobem dal definovat jako soubor dat. Systém souborů systému Unix je charakterizován [11]: hierarchickou strukturou konzistentním přístupem k datům souboru možnost vytvářet a rušit soubory dynamickým zvětšováním souborů ochranou dat v souborech k různým periferním zařízením se přistupuje jako k souborům 2.2 Klasický systém souborů v Unixu Při instalaci systému Unixu je třeba se rozhodnout, jaký systém souborů se bude používat. Na výběr máme nepřeberné množství několika odlišných typů, ale všechny však obsahují několik následujících komponent [11]: zaváděcí blok (boot block) pro zavlečení systému při spuštění počítače, obvykle 8kB superblok popisující stav systému souborů. Nese v sobě informace o typu, velikosti, počtu I-uzlů, volném místě, volných blocích, kde se nachází kořenový adresář apod. Superblok následuje hned po zaváděcím bloku. tabulka I-uzlů (i-nodes), jedná se oblast, která většinou následuje hned za superblokem. Je to tabulka s popisy souborů, každý soubor má své jedinečné číslo I-uzlu na které se jádro systému odkazuje. Jeden z I-uzlů je rezervován pro kořenový adresář jehož číslo je 2. Prostřednictvím tohoto I-uzlu je přístupná celá adresářová struktura systému souborů. datové bloky (data blocks) začínající hned za tabulkou I-uzlů
4 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ Z Ilustrace 1 je patrná posloupnost komponent souborového systému. Jak již bylo zmíněno na celou tuto strukturu se dá nahlížet jako na databázi tvořenou jedním souborem a na jednotlivé buňky jako na ukazatele na data. S výjimkou první položky tj. zaváděcího bloku. Ilustrace 1: Schéma systému souborů S5 2.2.1 Zaváděcí blok Zaváděcí blok zabírá začátek systému souborů, v typickém případě první sektor, a může může obsahovat zaváděcí kód. Tento zaváděcí kód se načte do počítače pro zavlečení nebo inicializaci operačního systému. Tento boot blok je součástí každého systému souborů a jak již bylo zmíněno, může i nemusí obsahovat zaváděcí kód. Jeho velikost v UFS je pevně dána a je 8kB. 2.2.2 Superblok Superblok popisuje stav systému souborů jak je veliký, kolik souborů lze do něj uložit, kde je možné najít v systému souborů volný prostor. Tato informace se uchovává v bitové mapě, kde jedničky reprezentují volné datové bloky a nuly ty bloky, které jsou již použité resp. obsazené [7]. Ilustrace 2: Bitová mapa Superblok obsahuje údaje pro správu celého souborového systému a skládá se z následujících položek: počet I-uzlů resp. velikost seznamu I-uzlů počet volných I-uzlů v systému souborů
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 5 index následujícího volného I-uzlu počet bloků v souborovém systému počet volných bloků index následujícího volného bloku velikost bloku. Vyjadřuje velikost bloku uvedením dvojkového exponentu pro počet 1024 bytových jednotek. Pro blok o velikosti 1024 bytů to je 0, pro 2048 bytové bloky 1, atd. rezervované bloky, umožňují administrátorovi pracovat se souborovým systémem tehdy, i když pro ostatní uživatele již nejsou k dispozici žádné volné bloky stav souborového systému 0 systém je připojen nebo nebyl bezchybně odpojen, například při havárii systému 1 byl bezchybně odpojený 2 obsahuje chyby. Je nutná kontrola konzistence dat při zavádění systému čísla bloku s prvním I-uzlem tabulky I-uzlů příznak indikující, že superblok byl modifikován Jádro operačního systému (OS) periodicky zapisuje superblok na disk, jestliže byl modifikován, takže je konzistentní s daty v systému souborů. 2.2.3 I-uzel Vnitřní reprezentací souboru je informační uzel, zkráceně I-uzel nebo anglicky I-node, který obsahuje popis uspořádání dat souboru a další informace. Například vlastníka souboru, přístupová práva, přístupově časy, typ soubor apod. Názvy souborů nejsou uchovávány v I-uzlu jak by se na první pohled mohlo zdát, ale v konkrétním adresáři. Každý soubor v Unixu může mít jenom jeden I-uzel, ale může mít hned několik různých i stejných jmen. Každé jméno se nazývá odkaz a každé jméno je jednoznačně identifikováno ve stromové hierarchii a je mu jednoznačně přiděleno jedinečné unikátní číslo I-uzlu. Historicky jsou I-uzly 0 a 1 určeny pro speciální účely, proto kořenový adresář má vždy číslo 2. Jednička historicky určovala ty datové bloky, které byly poškozené nebo vadné. Z Ilustrace 3 [6] je patrné, jak vypadá struktura jednotlivých I-uzlů v tabulce I-uzlů. Velikost jednoho I-uzlu je 128B. Pokud blok bude mít velikost 1024B potom tento blok obsahuje 1024/128=8 Iuzlů. Podívejme se nyní na jeden Iuzel a detailně si projdeme každou položku ve směru zleva doprava, shora dolů [8]:
6 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ Type/Mode Staré UserID Čítač linků Staré GroupID Velikost souboru v bajtech Poslední čas přístupu v sec Poslední čas změny souboru v sec Poslední čas změny v I-uzlu v sec 12 přímých adres Nepřímé adresy první úrovně Nepřímé adresy druhé úrovně Nepřímé adresy třetí úrovně Status Flag Počet kolik soubor zabírá DB Generační číslo Vlastník souboru Skupinový vlastník souboru Rezervováno pro budoucí využití 32 bitů Ilustrace 3: Struktura I-uzlu prvních 16bitů udává o jaký typ souboru se jedná (adresář, blokový soubor, obyčejný soubor, ) čítač linků na daný soubor. Pokud klesne na nulu, tak je tento soubor smazán. tyto dvě položky se dnes nevyužívají tj. UserID a GroupID. Jedná se o starý typ UFS. velikost souboru v bajtech a zabírá dvakrát 32bitů tj. 64bitů. čas posledního přístupu do souboru. 64Bitů, ve starém UFS se používalo jenom 32bitů. Takto bychom mohli ukládat čas jenom do roku 2031. čas poslední změny v souboru. čas poslední změny v I-uzlu. následuje 12 přímých datových 32bitových adres na datové bloky. Pokud máme datový blok o velikosti 8kB a máme soubor veliký 16kB potom první dvě adresy v I-uzlu budou ukazovat na datové bloky, kde je uložen daný soubor. To znamená, malé soubory budou adresovány přímými ukazateli na datové bloky. pokračují další adresy a to nepřímé datové adresy. Co to znamená? Máme tři úrovně nepřímé adresace. první úroveň (Indirect block) ukazuje na speciální datový blok, kde jsou uloženy již přímé adresy na datové bloky.
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 7 druhá úroveň (Double indirect block) nepřímých datových adres ukazuje na datové bloky první úrovně. Ilustrace 4: Adresace datových bloků třetí úroveň (Triple indirect block) odkazuje na druhou úroveň, ta zase na první úrpveň viz Ilustrace 4 ze str.7 hned po adresách třetí úrovně je v I-uzlu položka Status Flag. Operační systém si takto poznačuje uzel se kterým pracuje a zapíše sem stav co právě s ním dělá, zdali jej nějak potřebuje pro sebe blokovat apod. v anglické terminologii je tato položka pojmenována jako block actualy held. Udává počet přidělených datových bloků. generační číslo se při prvním použití tohoto uzlu nastaví na jedničku. Pokud se tento uzel uvolní a následně znova použije, zvýší se tato položka o jedničku. předposlední využívaná položka je číslo vlastníka daného uzlu poslední je číslo skupiny uzlu, která jej vlastní na úplném konci jsou dvě položky o velikosti 2x32bitů, které jsou nevyužity. Původně bylo rezervováno pro budoucí použití. Dnes se nevyužívá. 2.2.4 Datové bloky Datové bloky obsahují data o souborech a administrativní data. Alokovaný datový blok může patřit jenom jednomu souboru v systému souborů. Datové bloky můžou mít různou velikost. Tato velikost se při namontování disku čte ze superbloku, kde je tato hodnota uchovávána.
8 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 2.3 Soubory v klasickém Unix systému souborů 2.3.1 Struktura běžného souboru I-uzel obsahuje tabulku obsahu, která slouží pro vyhledávání dat souboru na disku. Protože každý blok na disku je adresovatelným číslem, skládá se tabulka obsahu z množin čísel diskových bloků. Předpokládejme, že data souboru jsou na disku uložena ve spojité oblasti disku, potom by stačilo pro přístup ke všem datům uchovat adresu počátečního datového bloku a velikost souboru. Takto definovaná struktura by neumožňovala dynamickou expanzi souboru nebo jeho zmenšování. Při každé takovéto operaci by to vedlo k fragmentaci volné diskové paměťové oblasti. Kromě toho by jádro operačního systému muselo alokovat a rezervovat spojitý prostor v systému souborů dříve, než by povolilo operace zvětšující velikost souboru. Kvůli větší flexibilitě alokuje jádro systému prostor po jednotlivých blocích a dovoluje tak, aby data souborů byla rozložena po celém systému souborů. Nutno podotknout, že takto zvolená strategie vede ke komplikovanějšímu vyhledávání dat. Připusťme, že tabulka obsahu by se mohla skládat ze seznamu čísel bloků, potom například soubor o velikosti 10kB a datový blok o velikosti 1kB by vytvářel seznam o velikosti 10 položek. Při souboru o velikosti 100kB by to bylo kolem 100 položek seznamu. Znamenalo by to buď proměnnou délku, velikost I-uzlu, v závislosti na velikosti souboru, nebo by velikost souboru musela být omezena nějakým nízkým limitem. Aby byla zachována neměnná relativně malá velikost I-uzlu a současně dovolovala uložit soubor jakkoliv veliký, je tabulka obsahu vytvořena tak, že obsahuje několik přímých adresových datových adres resp. čísla bloků ukazující na diskové bloky. Tyto bloky obsahují skutečná data uloženého souboru. Dále tabulka obsahu obsahuje tři nepřímé adresy datových bloků resp. čísla datových bloků obsahující seznam čísel přímých bloků nebo zase seznam čísel dalších nepřímých datových bloků viz. Ilustrace 4 ze str.7. Systém souborů S5 pracuje s 13 záznamy v tabulce obsahu I-uzlu: 10 záznamů je tzv. přímých tj. obsahují skutečné adresy na datové bloky souboru. 11 záznam obsahuje nepřímé číslo bloku první úrovně odkazující na blok obsahující seznam čísel přímých bloků. Pro přístup k datům přes nepřímý blok musí jádro systému načíst nepřímý blok, najít odpovídající blok a přečíst již přímé adresy datových bloků. 12 a 13 záznam obsahují záznam na nepřímé datové adresy druhé a třetí úrovně. Blok druhé úrovně obsahuje adresy datových bloků první úrovně a analogicky s předchozím bodem. Blok třetí úrovně obsahuje adresy nepřímých datových bloků druhé úrovně. V principu je možné podobnou strukturu rozvíjet na čtvrtou a další úroveň, ale v praxi se ukazuje, že třetí úroveň je naprosto postačující. Uvedeme si jeden početní příklad, který nám na číslech názorně ukáže, že třetí úroveň nepřímých datových adres je postačující: Předpokládejme, že datový blok je 1024B veliký a že číslo datového bloku je adresovatelné číslem integer tj. délky 32bitů tj. 4 slabiky resp. 4B. Z toho plyne,
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 9 že jeden blok pro nepřímou adresaci může obsahovat 1024/4=256 záznamů resp. 256 adres na datové bloky. Se znalostí předem nastíněné problematiky záznamů adres v I-uzlu, je možné uložit v S5 soubor o maximální velikosti 16GB a to při použití 10 přímých datových adres, 1 nepřímou datovou adresu první úrovně, 1 druhé úrovně a 1 třetí úrovně. 10 přímých adres je 10*1024B = 10kB 1 nepřímá adresa první úrovně je 256*1024B = 256kB 1 nepřímá adresa druhé úrovně je 256*256*1024B = 64MB 1 nepřímá adresa třetí úrovně je 256*256*256*1024B = 16GB Efektivita tohoto algoritmu je sporná. Záleží na velikosti souborů a na tom, jak je celý systém nastaven. Zdali přistupuje k velkým souborům častěji nebo k malým. Bylo ovšem zjištěno, že většina souborů v Unixu je menší jak 10kB dokonce méně než 1kB. Proto navzdory tomu, že přístup k velkým souborům představuje nákladnou operaci, je přístup k běžným souborům velice rychlý. Pro větší diskové bloky hovoří to, že čím větší počet dat je k dispozici jádru, tím je operace rychlejší a tím je také rychlejší přístup k souborům. Na druhou stranu čím větší je diskový blok, tím se zvyšuje fragmentace tj. nevyužitý datový prostor v rámci jednoho bloku. Je-li například velikost logického bloku 8kB velká a soubor je 10kB veliký, potom bude využit 1 kompletní blok a jenom ¼ druhého. Zbylé ¾ zůstanou nevyužity a žádný další soubor nemůže tento prosto využít. Pokročilejší verze UFS toto situaci řeší tak, že pro uložení dat z konce souboru se alokuje jenom zlomek bloku. Jeden diskový blok může potom obsahovat zlomky patřící několika souborům [11]. 2.3.2 Adresář V Unixu je vše soubor, proto adresáře jsou speciální typ souboru. Tyto soubory dávají systém souborů jeho hierarchickou strukturu. Adresář je soubor, jehož data jsou tvořena posloupností záznamů skládající se z čísla I-uzlu a jména souboru v adresáři uloženého. Jádro operačního systému ukládá data adresáře, stejně jako ukládá data běžného souboru, s použitím struktury I-uzlu a bloků přímé či nepřímé adresace. Protože je adresář soubor, mohou jednotlivé procesy číst adresář stejným způsobe jakým čtou soubor, ale jádro si vyhrazuje výhradní právo zapisovat do adresáře. Tím si zajišťuje jeho korektní strukturu. Ilustrace 5: Nalezení cesty /etc/passwd v UFS Stará verze souborového systému S5 využívala pro ukládání názvů souborů v souboru adresář přesně definovanou posloupnost znaků 16Bytových znaků. První dva byty 2B znamenají číslo I-uzlu, zbylých 14B pro znaky názvu souborů. Z toho plyne, že maximální délka názvu souboru v S5 je 14 znaků.
10 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ Novější verze UFS tento limit posouvá na 255 znaků. Tabulka 1 ze str.10 a Tabulka 2 ze str.10 zobrazují jak je definována vnitřní struktura souboru typu adresář v UFS. Všechny sloupce, kromě sloupce posledního, mají velikost intergeru tj. 32bitů tj. 4B. I-uzel Jméno 23. 5.. 53 mark 61 richard Tabulka 1: Struktura adresáře v S5 I-uzel Délka záznamu Délka jména 23 12 1. 5 12 2.. 53 12 4 mark Jméno 61 40 28 velice dlouhý název souboru Tabulka 2: Struktura adresáře v UFS 2.4 Unixový systém souborů (UFS) Jak již bylo zmíněno v úvodu, USF má naprosto stejnou funkcionalitu v porovnání s S5. Hlavní přínos byl v rozvržení disku. Kromě rozdělení disku na oblasti, které obsahují souborové systémy, rozděluje BSD oblast dále na skupiny malého počtu válců (cylinder group), které obsahují bloky se souvisejícími I-uzly a datovými bloky. S dalším růstem velikostí disků a růstem velikosti souborů se čtení fragmentů přinášelo stále více problémů, proto bylo rozhodnuto navýšit v nové verzi BSD FFS velikost datového bloku. Z původních 1kB ve verzi 4.0BSD na 1kB až 8kB v nové verzi FFS. Navýšení velikosti datového bloku mělo několik důsledků [1]: 1. Větší šance na obsazení datových bloků v řadě za sebou jedním souborem. 2. Režie na přečtení jednoho souboru se snížila. 3. Počet možných bloků, který je reprezentován číselnou hodnotou se zvýšil. To umožňuje nasazení UFS na větší disky. S velkými datovými bloky a malými soubory dochází k plýtvání místem na disku, proto byla zavedena tzv. fragmentace bloků. Blok může být rozdělen na 1, 2, 4, 8 fragmentů s nejmenší velikostí rovnající se velikosti sektoru tj. 512B Každý disk je rozdělen na stejně velké čísti zvané skupina válců cylinder groups. Velikost skupiny válců je v desítkách MB tj. skupin je až několik stovek. Ilustrace 6 znázorňuje přibližnou struktura BSD FFS souborového systému.
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 11 Cylinder groups 0 Cylinder groups 1 Cylinder groups 2 Cylinder groups n Zaváděcí blok (8kB) Datové bloky Datové bloky Datové bloky Superblok Cylinder groups map Superblok I-uzly Cylinder group map Superblok Datové bloky I-uzly Cylinder group map Datové bloky I-uzly Superblok Datové bloky Cylinder group map I-uzly Datové bloky Ilustrace 6: Skupina válců (cylinder groups) Cylinder group map se dělí na několik částí: 1. deskriptor skupiny válce cylinder group summary 2. bitová mapa volných I-uzlů 3. bitová mapa volných volných datových bloků. Protože se datové bloky adresují podle fragmentů, jedná se o bitovou mapu fragmentů Hlavní myšlenku skupiny válců může shrnout do několika bodů: každá skupina válců nese kopii superbloku místo pro ukládání I-uzlů vlastní bitové mapy alokovat pro jeden I-uzel 2048B místa ukládat příbuzné informace pospolu do stejné skupiny válců a nepříbuzné informace ukládat do jiných skupin válců snažit se ukládat veškeré I-uzly ve stejném adresáři do stejné skupiny válců snažit se ukládat datové bloky souboru do stejné skupiny válců jako je I-uzel pro každých 1MB alokovat novou skupinu válců. To má za následek roztroušení velkých souborů na disku, na druhou stranu se udržují celkem velké bloky dat v řadě za sebou a zlepšuje se tím lepšího času čtení souboru. 2.4.1 Zaváděcí blok Obdobně jako v klasickém systému souborů. Slouží k zavlečení systému, jeho velikost je 8kB 2.4.2 Superblok Oproti klasickému systému souborů přibyli některé nové položky. Z Ilustrace 6 ze str.11 si je možné všimnout, že superblok se opakuje v každé skupině válců. Jedná s opravdu o opakování resp. kopii superbloku z první skupiny válců označené číslem 0. To je z důvodu havárie nebo poškození disku. Superblok totiž obsahuje veškeré důležité informace o struktuře souboru systémů. Pokud by došlo ke ztrátě tohoto
12 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ bloku, dojde ke ztrátě všech informací uložených na disku. Aby se předešlo podobným tragédiím, bylo rozhodnuto a zabudováno do UFS, že superblok se bude kopírovat na všechny skupiny válců. Tím se při případné ztrátě prvního superbloku eliminuje ztráta všech dat. Je dobré si povšimnout, že superblok v dalších skupinách válců není uložen vždy na pozici 8kB, ale je posunut o nějakou délku. V případě ztráty prvního superbloku se nám tímto poněkud komplikuje nalezení další kopie superbloku. Toto posunutí má však svá opodstatnění. Děje se tak z důvodu bezpečnosti, obdobně jako když se kopíruje superblok na všechny skupiny válců. Již víme, že UFS je rozdělen na skupiny válců, dále víme jak je konstrukčně koncipován disk viz. Ilustrace 7 ze str.12. Potom předpokládejme, že struktura všech skupin válců je stejná jako v případě prvního válce, bez zaváděcího bloku. Potom by byl superblok uložen hned ze začátku nové skupiny válců. V případě havárie disku, konkrétně při havárii prvního disku platter. Nemusí nutně dojít k poškození celého plata, stačí aby došlo k poškození několika sektorů viz. Ilustrace 8 [2] ze str.13. Kdyby se tak hypoteticky stalo a na kritických místech by se nacházela kopie superbloku, ztratili bychom tak nenávratně veškerá data z celého disku resp. obnova by byla nemožná. Analogicky při poškození celého disku platteru bychom nedokázali obnovit data ze zbylých disku. Kopie superbloku se vždy ukládá až na následující disk platter, aby se zamezilo výše zmíněným katastrofám. Pokud dojde k nepříjemné situaci, ztrátě prvního supebloku, nalezení náhradní kopie není tak jednoduché jakby se na první pohled zdálo. Kontrola konzistence trvá dlouho, nalezení náhradní kopie není jednoduchou záležitost a vyžaduje ruční zásah uživatele. Záchranný program hledá na disku stejné sekvence bytů, orientuje se na magická čísla uložená v superbloku a stejné sekvence bytů na různých platterech disku. Protože program si není nikdy na 100% jistý, že nalezl ten správný blok, nabídne uživateli několik možností nalezených kopií, které je nutné ručně potvrdit, aby se mohlo pokračovat v následné záchraně dat. Ilustrace 7: Fyzická geometrie disku č.1
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 13 Ilustrace 8: Fyzická geometrie disku č.2 2.4.3 Deskriptor skupiny válce cylinder group summary Jedná se obdobu o superbloku pro skupinu válce. Je umístěn hned po kopii superbloku. Uchovává obdobné informace o své skupině jako superblok [8]. Jednotlivé buňky jsou adresovatelné integerem tudíž velikost je 32 bitů. Ilustrace 9 ze str.14 se již tradičně prochází shora dolů: tato položka je nevyužita zde je zapsáno magické číslo, které se skládá ze 4 znaků. Pro UFS1 a UFS2 se jedná o číslo 00 09 02 55 [5] nevyužito číslo konkrétní skupiny válců nevyužito udává počet všech datových bloků ve skupině válců počet adresářů počet volných datových bloků ve skupině válců počet volných I-uzlů počet volných fragmentů tato položka udává adresu datového bloku, která byl naposledy v této skupině válců alokován adresa posledního alokovaného fragmentu v dané skupině válců
14 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ obdobně jako předchozí dvě položky, adresa resp. číslo I-uzlu, který byl naposledy alokován systémem následuje 8 možných volných adres fragmentů 64bitů nevyužitého prostoru adresa na datový blok s bitovou mapou I-uzlů adresa na datový blok s bitovou mapou fragmentů adresa dalšího volného místa ve skupině válců počet clusterů k dispozici adresa na datový blok s bitovou mapou datových bloků počet datových bloků ve skupině válců počet I-uzlů ve skupině válců číslo posledního inicializovaného I-uzlu nevyužito a poslední 64bitové číslo udává poslední čas zápisu ve skupině válců Nevyužito Magické číslo Nevyužito Číslo skupiny válců Nevyužito Počet DB ve skupině Počet adresářů Počet volných datových bloků Počet volných I-uzlů Počet volných fragmentů Adresa alokovaného DB Adresa alokovaného fragmentu Číslo alokovaného I-uzlu 8 možných adres volných fragmentů Nevyužito Adresa bitové mapy I-uzlu Adresa bitové mapy fragmentů Adresa dalšího volného místa Počet clusterů k dispozici Adresa bitové mapy DB Počet DB ve skupině Počet I-uzlů ve skupině Inicializovaný I-uzel Nevyužito Poslední čas zápisu 32 bitů Ilustrace 9: Struktura deskriptoru skupiny válce
KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ 15 2.4.4 Bitové mapy Pro správu volného prostoru na disku resp. ve skupinách válců se v UFS používá bitová mapa. Z Ilustrace 2 ze str.4 je patrný význam jedniček a nul v bitové mapě. Jednička znamená volný datový blok, I-uzel nebo fragment a obráceně nula specifikuje, že datový blok, I-uzel nebo fragment je zabrán [7]. Každá bitová mapa má konstantní velikost a musí být uchována jenom v jednom datovém bloku. Z toho plyne, že máme-li například datový blok o velikosti 1024B, potom bitová mapa může opisovat maximálně 8192 datových bloků. Je-li k dispozici datový blok o velikosti 4096B, pak bitová mapa popisuje maximálně 32 768 datových bloků. 2.5 Soubory v UFS 2.5.1 Struktura běžného souboru Vše podstatné bylo již zmíněno v kapitole na str.. Snad jenom doplním něco o fragmentaci resp. adresaci datových bloků v I-uzlu. Jak bychom asi předpokládali datové bloky jsou adresovatelné číslem, pravděpodobně integerem, první datový blok, který je umístěn hned za tabulkou I-uzlů bude mít číslo 0. Následující datový blok bude vedeny pod čísly 1,2... až n Takto dokážeme krásně adresovat všechny datové bloky, nikoliv fragmenty datových bloků. Pokud bychom chtěli podporovat fragmentaci v systému souborů aniž bychom museli měnit strukturu I-uzlů nebo jiné změny, bylo zavedeno, že všechny ukazatelé, čísla na datové bloky, budou udávány jako čísla fragmentů. Číslo fragmentace udává na kolik dílků je rozdělen datový blok. UFS podporuje tyto fragmentace s čísly 1,2,4,8. Je-li číslo fragmentace 1, potom se datový blok již dále nedělí. Dvojka rozpůlí datový blok na dvě části, čtyřka na čtyři apod. Mějme systém souborů s fragmentací 8. První blok bude přístupný pod číslem(adresou) 0, následující jako 8, další datový blok bude mít adresu 16,24,32...až n Tímto způsobem jsme zajistili, že se nemusí měnit struktura I-uzlů nebo zavádět nové adresy pro fragmenty datových bloků a náš systém souborů od této chvíle umí podporovat fragmentaci. Pro uchování informace jakou fragmentaci jsem právě použily, slouží položka v superbloku, kam se při instalaci UFS zapíše. Tato položka je již dále neměnná tj. nemůžeme ji již po instalaci souborového systému nijak měnit. 2.5.2 Adresář Adresáře jsou systémové soubory, které udržují strukturu systému souborů. Na strukturu adresáře se dá nahlížet několika způsoby. Tabulka 2 ze str.10 ukazuje jeden pohled, Ilustrace 10 ze str.16 druhý. Každý záznam názvu souboru v adresáři by měl být bezezbytku dělitelný slovem tj. 32bity tj. 4B. První položka je číslo uzlu jejíž velikost je integer 4B. Následuje velikost záznamu v bytech tj. kolik bytů zabírá záznam jména včetně čísla I-uzlu, velikosti a délky. Délka určuje délku názvu souboru v bytech. V tomto případě se jedná o velikost 16B a délka je 6B. Zarovnání znamená, že to jsou nevyužity dva byty, které fakticky zarovnaly celý záznam aby byl bezezbytku dělitelný 4B.
16 KAPITOLA 2 VNITŘNÍ REPREZENTACE SYSTÉMU SOUBORŮ Číslo I-uzlu Velikost Délka S O U B O R Zarovnání 32 bitů Ilustrace 10: Struktura adresáře v UFS2 Základními požadavky na adresář jsou: procházení souborovým systémem. V praxi to znamená nastavení pracovního adresáře (přepnutí se do adresáře) výpis adresáře tj. jaká jména souborů jsou v daném adresáři vytváření a rušení souborů. Je dobré připomenout, že v Unixu se soubory ruší jedině tehdy, když čítač liknů v I-uzlu se nastaví na nulu viz. Ilustrace 3 ze str.6 přejmenování souboru
KAPITOLA 3 ANALÝZA 17 3 Analýza Úkolem je vytvořit výukový systém UFS, který bude umožňovat detailní pohled na systém souborů v Unixu. Většina systémů souborů v Unixu je postavena na obdobných základech, každý obsahuje superblok, datové bloky, bitové mapy a tabulku I-uzlů. Jednotlivé implementace systému souborů v Unixu se jenom nepatrně liší, hlavní myšlenka je stejná, bude na ní stavět výukový systém UFS. Osvětlit problematiku I-uzlů, datových bloků a jak jsou realizovány bitové mapy. 3.1 Volba programovacího jazyka Jako vývojové prostředí se nejlépe hodí programovací jazyk Java. Tato volby nebyla náhodná neb se jedná o jazyk se silnou orientací na objekty a je multiplatformní. Multiplatformní znamená, že je portabilní, aplikace vytvořené v programovacím jazyce Java se dají běžně bez větších omezení portovat na většinu známých i méně známých operačních systémů. Například Linux, Solaris nebo Windows. Jak již bylo zmíněno výhodou jazyka Java je jeho objektová orientace, další jeho nespornou výhodou je, že je deterministický, všechny úlohy končí či havarují určitelným způsobem [10]. Je spolehlivý, robustní, dobře dokumentovaný a bezpečný. Široká nabídka grafických tříd GUI (Graphical User Interface) [9] v Javě, umožňují dobrou vizuální a interaktivní komunikaci mezi člověkem a počítačem. Tak jako vše v Unixu je soubor například adresář, bloková zařízení, jiná speciální zařízení, tak v Jazyku Java je vše objekt. Jistá analogie by tu byla, proto nic nebrání tomu, zvolit programovací jazyk Java jako hlavní vývojové prostředí. Jedná se o výukový systém a jako takový by měl splňovat podmínku široké rozšířitelnosti mezi uživateli (měl by být portabilní mezi platformami), tak bezproblémového ovládání a bezpečnost. Všechny tyto požadavky splňuje jazyk Java. 3.1.1 Applet Jedná se o Javský program, který upraven tak, aby se dal spustit v prohlížeči klienta. Stáhne-li prohlížeč z http-serveru HTML stránku a jsou-li na této stránce párové značky <applet>, potom prohlížeč vytvoří na stránce appletové okno, stáhne bytekód programu z definované cesty a spustí ho. 3.2 Omezení appletu Aby applet nemohl škodit klientskému počítači má standardně omezené některé možnosti, které normální program nemá. Applet nemůže : přistupovat k lokálním souborům resp. přistupovat k souborům na straně klienta a pracovat s nimi. Myšleny operace čtení a zápisu zjišťovat a měnit vlastnosti systému, nemůže číst některé citlivé proměnné a nemůže modifikovat systémové proměnné vytvářet knihovny a definovat nativní metody spouštět programy na straně klienta
18 KAPITOLA 3 ANALÝZA navazovat síťovou komunikaci s třetí stranou nemůže ukončit práci virtuálního stroje JVM (Java Virtual Machine) Tato omezení může klient zmírnit buď podepsáním appletu bezpečnostním klíčem nebo politikou tzv. policy. Děje se tak udělením tzv. grantů specificky na určité operace. Při pokusu o překročení daných omezení je vyvolána výjimka java.security.accesscontrolexception. 3.2.1 Podepsání appletu digitálním certifikátem Způsob podepsání appletu digitálním certifikátem potvrzuje, že applet je vytvořen námi a uživateli dává možnost označit nás jako důvěryhodného a povolit tak appletu přístup k omezeným operacím. Při prvním spuštění appletu prohlížečem je vyvolán Java modul, který vyžaduje po uživateli rozhodnutí zdali přijmout či odmítnout digitální certifikát. Pokud se rozhodneme odmítnout, potom applet se spustí omezeními, které jsou pro něj typické. Podepsání appletu je rozděleno do dvou resp. jednoho kroku. Pokud nemáme vytvořený žádný klíč, kterým bychom applet podepsali, musíme si jej vytvořit. To se provede následujícím příkazem v příkazové řádce: keytool -genkey -alias názevklíče Příkaz se dotáže na několik informací nutné pro zdárné vytvoření klíče a na závěr se dotáže na heslo. Při podepisování JAR souboru se aplikace, která podepisuje tento soubor, dotazuje na ověření tohoto hesla. Samotné podepsání JAR archívu se provádí programem jarsigner: jarsigner můjsoubor.jar názevklíče Takto podepsaný archív je možné následně vložit na webové stránky a od této chvíle applet jsou zmírněna některá bezpečnostní omezení Java appletu. 3.2.2 Politika udělení grantu appletu Další možností jak zmírnit některá bezpečnostní omezení, je prostřednictví přidělení grantu na některé specifické operace resp. na všechny. Pomocí souboru java.policy v domovském adresáři uživatele stačí zapsat položku pro jednotlivé servery v tomto tvaru: grant codebase http://127.0.0.1/- { }; permission java.security.allpermission; Tento způsob přidělování grantů je zvláště vhodný pro ladění appletů na lokálním počítači. 3.3 Cíl práce Celou práci je možné rozdělit do dvou velkých programových částí: 1. vytvoření jádra celého systému 2. vytvoření grafické uživatelské prostření
KAPITOLA 3 ANALÝZA 19 3.3.1 Jádro systému UFS pochází z prostředí Unixu, proto výukový systém UFS bude zasazen jakoby do virtuálního prostředí Unixu. Veškeré operace, které uživatel vykoná, se předají ke zpracování jádru systému. Jádro bude postaveno na základě definovaných pravidel UFS z kapitoly. To znamená, že musí vykonávat veškeré operace související s uložením souborů, jejich mazání a přejmenováním. Jádro musí udržovat konzistenci dat a hierarchickou strukturu adresářů. 3.3.2 Grafické uživatelské prostředí Cílem práce je vytvoření uživatelsky přívětivého prostředí. Pro uživatele by grafické prostředí mělo připomínat terminál operačního systému Unix. Tak jak je uživatel zvyklý z Unixu, v příkazové řádce se zadají příkazy a klávesou enter se předají ke zpracování jádru. Příkazy jako ls, mv, cd a mnoho dalších jsou k dispozici v terminálu grafického prostředí. Takto vytvořený terminál nám nepodá žádnou ucelenou, pokud možno graficky přehlednou, informaci o uložených datech. K tomuto účelu je zapotřebí vytvořit nějaké rozhraní, kde si každý může prohlédnout změnu, která se provedla po vykonání příkazů z terminálu, například přesunutí souboru z jednoho adresáře do druhého. Z kapitoly 2.3.2 ze str.9 víme, že se jedná o operaci smazání jména ze souboru typu adresář a vložení daného jména do jiného souboru typu adresář. Protože celý výukový systém je vytvářen jako applet, je nutné zajistit natažení některých souborů z vnějšího prostředí. Jde o to aby si šlo představit jak se uloží takový soubor v systému souborů UFS. Pro tento účel musí být k dispozici prostředí, kde je možné tuto funkci a jí podobné vyvolat.
20 KAPITOLA 3 ANALÝZA
KAPITOLA 4 REALIZACE 21 4 Realizace Nejvhodnějším vývojovým prostředím pro realizaci celého výukového systému UFS byla zvolena aplikace Eclipse. Tento program je nabízen od firmy IBM zadarmo jako freeware pro všechny platformy a nabízí řadu užitečných nástrojů pro tvorbu projektů v jazyce Java. 4.1 Java To že v Javě je vše objekt již víme. Výhody jazyku Java byly zmíněny a podrobně popsány v kapitole 3.1 na str.17. Méně se probíraly výhody a nevýhody GUI, proto se nyní zaměříme na tuto problematiku. 4.1.1 Balíček java.awt Obsahuje komponenty jako jsou knoflíky, textová pole, menu, posuvníky, grafiku s množstvím grafických primitiv apod. Tyto komponenty se dají velice jednoduše vkládat do kontejnerů a samotné komponenty se rozmisťují na ploše kontejnerů pomocí tzv. layout manažerů. viz. kapitola 4.1.3 str.21. Pro pojednávání událostí a jejich zachytávání slouží balíček java.awt.event. Podstatné vylepšení GUI nese Java v sobě od verze 1.2 pod názvem javax.swing, bylo rozhodnuto vytvářet celý výukový systém UFS v tomto grafickém prostředí. 4.1.2 Balíček javax.swing Swing je velmi vylepšené GUI funkčně, esteticky i ergonomicky [3]. Je součástí JFC (Java Foundation Classes) a ta je standardní od verze 1.2. JFC dále zahrnuje 2D grafiku, lepší tisk, Accesibility a DnD (Drag And Drop tj. ovládání gesty myší). Swing nezávisí na platformě (Windows, Linux, MacOS), může dynamicky měnit vzhled komponent dle vkusu uživatele díky vlastnosti LookAndFeel a to ve stylu Windows, Motif anebo Metal. Na rozdíl od AWT využívá Swing tzv. lightweight komponenty (které vytváří Java a nikoli platforma). Swing staví komponenty na koncepci MVC (Model-View-Control) [3] a usnadňuje modifikace a tvorbu dalších komponent. Pro zrychlení mnohé komponenty nejsou synchronizované. Využívá i starší třídy AWT ke konstrukci komponent s obdobnou funkcionalitou např. Button / JButton, Label / JLabel, Frame / JFrame, Applet / JApplet apod. 4.1.3 GUI (Graphical User Interface) Výukový systém UFS používá pro zobrazení ovládacích prvků, polí atd. většinu známých komponent (JButton, JPane apod.) a několik méně používaných např. JTabbedPane. Pro vkládání komponent do kontejnerů se používá metoda add ve tvaru add(komponenta). Abychom jednoduše mohli rozmisťovat jednotlivé komponenty po kontejneru, využíváme k tomu několik Layout manažerů. Ve výukovém systému byly použity následující tři Layout manažery [9]:
22 KAPITOLA 4 REALIZACE 1. BorderLayout, při rozmísťování komponent do světových stran. Toho se využilo tehdy, když bylo zapotřebí umístit několik malých postranních komponent a jednu velkou na zbytek kontejneru. Vhodné pro umístění tzv. menu na jednu stranu, kam se vloží tlačítka na zbytek se vykresluje případný grafický výstup. 2. GridLayout, pro roztažení jedné komponenty na celý kontejner. 3. FlowLayout, tzv. plovoucí rozmísťování komponent, vhodné při vycentrování. 4. GridbagLayou, nejsložitější, ale na druhou stranu velice dobře využitelný manažer. Celý kontejner je rozdělen na mřížku, do které se vkládají komponenty. Tyto komponenty mohou být vloženy buď do každé buňky, nebo přes několik buněk. Je jedno jestli v řádku či ve sloupci. Pro vkládání komponent do kontejneru platí jednoduché pravidlo. Vkládaná komponenta se umístí vlevo na první řádek. Pokud se na daný řádek již nevleze žádná další komponenta, je umístěna na následující atd. Při vykreslování některých grafických primitiv se vystačilo s grafikou z balíčku java.awt, pro vykreslování přerušovaných čar se výborně hodil balíček s 2D grafikou. Nejprve je nutné zajistit přetypování starého grafického rozhraní na nové. To se provede příkazem: Graphics2D newgraphics=(graphics2d)oldgraphics; Nyní již můžeme používat 2D grafiku pro přetypovanou třídu. Jednou z velice důležitých metod v appletu je metoda paint() Tato metoda se volá při každém spuštění appletu nebo při změně fokusu prohlížeče. Jakmile chceme zajistit vykreslení požadovaných kontejnerů nebo grafických primitiv, musíme přetížit tuto metodu. A v ní definovat potřebná rozmístění resp. vykreslení požadovaných grafických primitiv a tím definujeme patřičný vzhledu appletu. 4.2 Návrh struktury implementace Z kapitoly 3.3 na str.18 víme, že výukový systém UFS bude rozdělen na dvě části. Na část sestávající z jádra a na část pro uživatelské rozhraní. Obě části budou tvořeny jako samostatné třídy. Třída jádra a ostatní třídy. Ilustrace 12 Na str.38 znázorňuje třídu jádra výukového systému pod názvem Data, spolu s třídou pro I-uzly Inode a s třídou pro obsluhu adresářů Dir. V hierarchické struktuře objektů výukového systému, pokud pomineme nadřazené třídy appletu, stojí JApplet. Ilustrace 11 na str.37 tuto skutečnost dobře znázorňuje. Vlevo uprostřed ilustrace se nachází objekt Japplet, který rodičem třídy First. Třída First, jak je z názvu patrné, je úvodní třídou celého výukového systému. Na ní navazují třídy Shell, Settings a Disk detailně popsané v kapitole 4.4 na stránce 24. 4.2.1 Třída jádra systému Tato třída se nazývá Data a tvoří hlavní část jádro celého systému. Tato třída má na starosti obsluhu všech metod, které se nějakým způsobem dotýkají práce s virtuálním diskem. Disk je tvořen bolem bytů, obdobně jako fyzický disk je tvořen polem bytů.
KAPITOLA 4 REALIZACE 23 Rozdíl je v tom, že fyzický disk je několikanásobně větší, což z důvodu omezené kapacity paměti klientských stanic nebylo možné simulovat. Z toho důvodu dochází k některým omezením výukového systému. Jeden z důvodů je již zmíněná velikost virtuálního disku. Toto omezení na druhou stranu usnadnilo lepší grafické znázornění celého disku. Pokud by byl disk hodně velký stával by se nepřehledným. Při malé velikosti disku by se grafické zobrazení uložení dat na disku stalo přehlednějším. Byl volen kompromis pro velikost virtuálního disku s ohledem na systémové prostředky klientských stanic a s ohledem na funkčnost resp. přehlednost výukového systému. Velikost disku je omezena na minimální velikost 128kB do 4MB. Virtuální disk s virtuálním systémem souborů je rozdělen na části obdobně jak znázorňuje Ilustrace 1 na str.4. S rozdílem, že nepotřebuje uchovávat informaci o struktuře UFS po ukončení práce s výukovým systémem, proto boot blok a super blok se nevyužívá. Veškeré nastavení systému zajišťuje třída Settings. Ta při změně nastavení výukového systému se jádru předávají veškerá nastavení. To je nastaveno tak, aby mohlo při prvním spuštění inicializovat tzv. novou instalaci disku s implicitním nastavením pomocí metody firtinit() ve třídě Data. Implicitní nastavení disku je jeho minimální velikost a velikost datového bloku 2048B. Počet I-uzlů je fixně nastaven na 64. Třída Data nese veškeré potřebné informace o virtuálním disku, proto byl superblok vypuštěn z grafického znázornění virtuálního disku výukového systému. Z důvodu přílišné nepřehlednosti se upustilo od zobrazování všech případných skupin válců. Pro názornou ukázku ukládání dat se stačí zabývat pouze první skupinou válců a ostatní může vypustit s tím, že veškerá funkcionalita UFS ve výukovém systému UFS je zachována. Jádro celého systému je zdánlivě nezávislé a jeho metody jsou volány převážně třídou Shell, která je virtuálním terminálem výukového systému. Ilustrace 14 Na str.39 znázorňuje všechny metody třídy Data. 4.3 Nároky na vybavení strojů a programů Pro správný chod appletu je vyžadován počítač s grafickým výstupem a nějakým okenním tzv. window manažerem. Java běží na všech známých platformách od Linuxu přes Windows až po MacOS. Bez okenního manažeru applet nejde provozovat. 4.3.1 Potřebné SW vybavení K tomu aby uživatelé mohli používat výukový systém UFS, potřebují dvě věci. Pokud možno novější prohlížeč. Výukový systém byl testován na FireFoxu a InternetExploreru bez zřejmých závad. Dále je nutná správná verze JRE (Java Runtime Environment), doporučená verze je 1.5 a vyšší. Se straší verzí 1.4.2 nebyl problém se spuštěním, ale vyskytl se blíže neidentifikovaný problém s podepsaným appletem. Když se JRE dotáže zdali uživatel souhlasí s uvolněním některých restrikcí a ať se zadá cokoliv, applet se nespustí. V případě, že applet není digitálně podepsán viz. kapitola 3.2.1 na str.18, tak k výše popsanému problému nedojde.
24 KAPITOLA 4 REALIZACE 4.3.2 Potřebné HW vybavení V rámci ladění a testování projektu se nevyskytl žádný požadavek na nějak specializovaný HW. Applet bez problémů běžel jak na velice archaických strojích s omezenou velikostí pamětí na 64MB, tak na nejnovějších počítačích. 4.4 Realizace uživatelského rozhraní Jak již bylo zmíněno dříve, celý výukový systém je rozdělen do dvou hlavních částí, na jádro a uživatelské rozhraní viz. kapitola 3.3 na str.18. Jádro bylo popsáno v kapitole 4.2.1 na str.22 a nyní se budeme podrobně zabývat uživatelským rozhraním výukového systému UFS. Grafické uživatelské rozhraní je tvořeno jediným kontejnerem do kterého je vložena komponenta JTabbedPane, která vytvoří záložky v horní části zobrazovaného okna, přes které se dá přistupovat k dalším třídám resp. k jiným kontejnerům s různým nastavením. Pro vložení nových záložek se volá metoda addtab() z třídy JTabbedPane. Máme tři třídy Shell, Disk, Settings potomky komponenty JPane. Pro vložení záložky Shell je zavolána metoda následovně: addtab( Nadpis záložky, Ikona, new Shell, podrobnější popis záložky ) Celá aplikace je rozdělena do třech hlavních bloků reprezentovanými třemi třídami. Jejich závislost je zřejmá z ilustrace 11 na str.37. Uživatelské rozhraní je tedy členěno na: 1. Unixový terminál reprezentován třídou Shell 2. grafická reprezentace disku třída Disk 3. nastavení výukového systému třída Settings Všechny tyto části jsou na sobě nezávislé, každý blok je samostatný objekt s možností přístupu na disk resp. s přístupem ke třídě Data, která jak bylo zmíněno zajišťuje veškerou komunikaci s virtuálním diskem. 4.4.1 Unixový terminál Shell resp. Unix terminál ve výukovém systému zvládá nejzákladnější příkazy shellu v Unixu tj. práce s adresáři a soubory: založení, rušení a přejmenování souboru založení, rušení a přejmenování adresáře zobrazit výpis obsahu adresáře změna pracovního adresáře vypsání velikosti disku a volného místa na disku Dojem Unixového terminálu je vytvořen pomocí komponenty JTextArea a GridLayout manažerem, který zajistí natažení vkládané komponenty na celou zobrazovanou plochu. Komponenta JTextArea je textové pole, do kterého se dá jednoduše psát, mazat a vkládat text, popřípadě je možné jej vyjmout. K zamezení vyjmutí a vložení textu jinak než přes klávesnici, je odchytáván veškerý pohyb kurzoru v textovém poli a předán ke zpracováni k tomu
KAPITOLA 4 REALIZACE 25 určené třídě KeyEv. K vepsání příkazů resp. znaků na správný řádek, zamezení vepsání nebo vložení textu na jinou pozici než je aktivní řádek a ke sledování klávesnice Enter slouží třída KeyEv podtřídy KeyAdapter s metodou keypressed(). Posluchač reaguje na události v textovém poli a předává řízení zmiňované třídě KeyEv a její metodě pro zpracování stisku klávesy. Ta zajistí, že kurzor bude vždy na té správné pozici a vkládané znaky se zapíší na aktivní řádek. Klávesa Enter zavolá metodu pro zpracování příkazu docommand() ve třídě Command určenou k vykonání daného příkazu. Pro zobrazení výstupu vykonaného příkazu se zavolá metoda getvystup() třídy Command kam se uložil výsledek zpracovávaného příkazu. Třída Command zpracovává následující příkazy: cd - změna aktuálního adresáře. Vyvolá metodu setcurrentdirinode() ze třídy Dir clear - vyčistí obrazovku terminálu disk - zobrazí velikost disku a volné místo na disku. Ze třídy Data volá metodu pro zjištění velikosti disku getdisksize() a pro velikost volného místa getfreediskspace() help - nápověda výukového systému UFS ls - vypíše informace o pracovním adresáři. Metoda readdir() ze třídy Dir mkdir - založí nový adresář. Ve třídě Data metoda mkdir() mv - přesune soubor do zadaného adresáře. Ve třídě Data volá dvě metody. První pro přidání nového jména do adresáře appendtodir(), druhá pro smazání jména z adresáře removefromdir() pwd - zobrazí současný adresář. Ve třídě Dir metoda getfilenameindir() rm a rmdir - odstraní soubor z disku. Ve třídě Data je zavolána metoda na dekrementaci čítače linků v I-uzlu tj. decreaselinkcount() 4.4.2 Grafické zobrazení uložení dat na disku Pro lepší pochopení jak jsou data na disku uložena slouží třída Disk. Jedná se o komponentu Canvas resp. plátno, na které se grafickými primitivy vykreslují zobrazované údaje. Zobrazovaná plocha je rozdělena na dvě části. Levou, s tlačítky pro změnu zobrazovaných oblastí a pravou, kde je umístěna komponenta Canvas na kterou se umísťují grafická primitiva. K dispozici jsou čtyři grafické výstupy: 1. úvodní popis struktury UFS, co to je boobt blok, superbblok, či skupina válců. Vysvětleny jsou významy sector, track nebo cylinder. 2. bitové mapy, zobrazuje zaplněnost jednotlivých datových bloků, I-uzlů
26 KAPITOLA 4 REALIZACE a fragmentů UFS 3. struktura I-uzlů s detailním pohledem na jednotlivé položky I-uzlu 4. datové bloky, zobrazující využitelnost jednotlivých datových bloků s možností prohlížení v textovém nebo šestnáctkovém módu. Úvodní kontejner je rozvržen pomocí BorderLayou manažeru. Využity jsou CENTER, pro kontejner Canvas a WEST pro kontejner s komponentami tlačítek. K vykreslování grafických primitiv slouží základní třída java.awt.graphics. Pro vykreslování náročnějších grafických primitiv je k dispozici třída Graphics2D. Při kreslení si nemůžeme přímo říci, kdy se která grafická komponenta vykreslí, to zajišťuje samotné awt. Můžeme si jenom určit co chceme, aby bylo vykresleno a awt zařídí vykreslení, kdy uzná za vhodné. K tomu abychom awt řekli, kdy má začít vykreslovat, slouží metody repaint(), paint() a update() ze třídy Component. Vlastní činnost kreslení grafických primitiv se děje pouze v metodě paint() kterou je nutné přetížit a je definována: public void paint(graphics g){ } // tělo metody V těle metody potom píšeme metody grafických primitiv, která se začnou vykreslovat dle výše zmíněných pravidel awt. Při jakékoliv změně v těle metody paint() se změna neprojeví na výstupu, ale jedině tehdy, když je zavolána metoda repaint(), která zajistí včasné vykreslení požadovaných změn. Ve výukovém systému se tak děje tehdy, když dochází k reakci na události vyvolané myší. Třída PlatnoBitMaps ve výukovém systému UFS zajišťuje všechny operace spojené s kreslením grafických výstupů. Jednotlivé metody jsou zobrazeny v UML diagramu na ilustraci 15 na str40. 4.4.3 Nastavení výukového systému UFS Rozmanitost v nastavení samotného UFS, například změna velikosti datového bloku, velikost fragmentace nebo různá interní nastavení skupin cylindrů vedla k myšlence umožnit uživateli provádět podobná nastavení jako kdyby tato nastavení prováděl při instalaci UFS na fyzickém disku. Některá nastavení nemají smysl u malých disků, jako je ten ve výukovém systému, proto ne všechna, ale jenom některá, byla zahrnuta do výukového systému. Patří mezi ně možnost změnit velikost virtuálního disku, tak jako kdybychom instalovali UFS na několik různě velikých fyzických disků. Jednou z důležitých inovací UFS byla možnost měnit velikost datových bloků, proto výukový systém zahrnuje tento typ nastavení. Co by to byl za výukový systém, kdyby si uživatelé nemohli na vlastních souborech vyzkoušet, jak výukový systém UFS pracuje. V této sekci appletu se jim tato možnost nabízí. V kapitole 3.2.1 na str.18 se podrobně rozebírají úskalí appletů resp. jejich některá bezpečnostní omezení a jejich řešení. Díky těmto řešením máme možnost číst soubory z klientského počítače resp. uživatel si sám určí, který soubor se může přečíst a ten se naimportuje do výukového systému
KAPITOLA 4 REALIZACE 27 a uloží se do kořenového adresáře značeným jako /. Kromě importování souborů na virtuální disk se všechny ostatní operace resp. změny týkající se nastavení UFS, projeví jako nová instalace UFS na nový disk. To je pochopitelné, nový disk rovná se nová instalace UFS. Můžeme si to představit jako příkaz mkfs.ufs v Unixu, protože po každém novém nastavení dojde k přeformátování disku s novými parametry. Veškeré operace se soubory, s adresáři, jejich přejmenování a mazání se okamžitě projevují na disku. Tyto změny se dají vysledovat v grafické části výukového systému, pokud se přepneme do této části appletu. Třídou pro nová nastavení je třída Settings s metodami zobrazenými na ilustraci 13 na str.38.
28 KAPITOLA 4 REALIZACE
KAPITOLA 5 TESTOVÁNÍ 29 5 Testování Všechny uvedené testy byly prováděny v průběhu realizace projektu, některé testy až po vytvoření celé aplikace. Black-box testování se osvědčilo v samém závěru neb dokázal odhalit některá nesprávná fungování funkcí resp. odhalil chybná chování appletu. 5.1 White-box testování Dle definice white-box testování [4] byly všechny samostatné cesty uvnitř jednotlivých modulů provedeny alespoň jednou. Všechna podmíněná větvení byla procházena jak podél větve s hodnotou ANO (true), tak podél větve s hodnotou NE (false). Pozornosti white-box tetování neušly ani všechny cykly v programu,. Byly prověřeny všechny vnitřní datové struktury. Bohužel u některých cyklů nebylo možné je procházet v plném rozsahu, proto se strategie testování některých cyklů redukovala na testování nejvnitřnějšího cyklu a ve všech vnějších cyklech se nastavil jejich průchod na nejmenší možný průchod. Touto metodou testování, došlo k odhalení některých chyb v programu. Při průchodu jedním z cyklem, který ukládal data došlo v jednu chvíli k vyhození výjimky. Stalo se, že proměnná používaná jako ukazatel na index v poli se inkrementovala špatně. Došlo k jejímu zvětšení nad přípustnou mez než je délka pole. Při pokusu o čtení z pole index byl překročen a došlo k vyhození výjimky. Zde se uplatnila jedna z mnoha předností Javy, kdy došlo k zastavení vykonávání kódu. Chyba byla v době testování kódu nalezena a následně opravena. 5.2 Black-box testování Toto testování bylo založeno na funkčních požadavcích. Vzhledem k white-box testování se jedná o doplňkovou resp. alternativní metodu. V black-box testování se hledají: nesprávné nebo chybějící funkce. Veškerou práci s odhalením chybějících funkcí provedlo vývojové prostředí Eclipse. Tento vývojový nástroj nedovolí ve striktním režimu spustit aplikaci, aniž by všechny zmíněné funkce ve zdrojovém kódu nebyly správně doprogramovány. Samozřejmě neodhalí metody a funkce, které byly vytvořeny jako prázdné. Ke snížení tohoto rizika se zavedlo, že každá nově vznikající funkce nebo metoda se v době výtvoru musí řádně doprogramovat chyby datových strukturou. Kód se prošel tak, aby byla zajištěna integrita datových struktur. Pro případné odhalení chyb, se použila metoda založená na grafu. Byly znázorněny všechny vztahy graficky a byl navržen test, který pokrýval takto vytvořený graf. chybné chování. Aplikace byla testována tak, aby bylo prověřeno její správné chování. Každá kombinace možného způsobu chování aplikace bylo otestováno. Se 100% jistoto se nedá tvrdit, že byly odhaleny všechny podobné chyby. Dá se předpokládat, že se jejich výskyt alespoň minimalizoval. chyby inicializace nebo skončení. Velkou výhodou Javy je, že je deterministickým jazykem. Veškeré úlohy končí nebo havarují
30 KAPITOLA 5 TESTOVÁNÍ určitelným způsobem. Odhalení podobných chyb se dělo v průběhu psaní kódu resp. v době ladění kódu.
KAPITOLA 6 ZÁVĚR 31 6 Závěr Úspěšně se podařilo vytvořit prostředí pro výukový systém UFS. Celý systém je úspěšně implementován v jazyce Java za pomoci vývojového prostředí Eclipse. Výukový systém je vytvořen tak, aby byl snadno portovatelný na všechny známé platformy bez nutnosti instalace. Java tuto možnost nabízí ve formě tzv. appletu a celý projekt je proto vytvořen jako Java Applet. Úspěšně se podařilo odstranit všechny nástrahy, které s sebou applety nesou, aniž by bylo nutné z výukového systému cokoliv vypustit. Podařilo se vytvořit obdobu Unixového terminálu, kde se zadávají příkazy do příkazového řádku tak, jak se zadávají v Unixu. Byla úspěšně implementována možnost nastavení celého výukového systému. Změna velikosti virtuálního disku nebo velikosti datového bloku je součástí appletu. Podařil se import souborů z klientských stanic na virtuální disk s možností nahlížení do jednotlivých datových bloků. Každý datový blok se dá zobrazit ve dvou režimech, v obyčejném textové nebo šestnáctkovém výstupu. Nepodařilo se dokončit a naprogramovat ukládání velkých souborů. Jedná se o soubory, jejichž uložení vyžaduje přístup k datovým blokům, které jsou adresovatelné pomocí nepřímých adres druhé a třetí úrovně. To by mohl být dobrý námět na další práci s možnými vylepšeními výukového systému UFS. Unix File System byl vytvořen ze starší verze souborového systému a navržen tak, aby neměl některá jejich omezení, které tyto starší verze měli. Jedním z nich bylo omezení velikosti disku, na který mohli být nasazeny. Bohužel to je právě opak toho, jaké jsou možnosti v prostředí Java Appletu. Prostředky klientského počítače, na kterém poběží applet, jsou omezené. Velikost virtuálního disku je v porovnání s velikostí fyzického disku miniaturní a tak všechna vylepšení, která sebou nese UFS se stávají nepoužitelná a nemají žádný efekt na výsledné ukládání dat na disk. Celý výukový systém je ve výsledku kombinací staré verze UFS resp. S5 s FFS, do které byly přidány všechna vylepšení z UFS2. Výsledný produkt není přesně dle specifikace UFS, ale zachovává všechna vylepšení, která s sebou UFS2 nese.
32 KAPITOLA 6 ZÁVĚR
KAPITOLA 7 SEZNAM POUŽITÉ LITERATURY 33 7 Seznam použité literatury [1] Guy Harris, Unix File System, 22.6.2006, http://en.wikipedia.org/wiki/berkeley_fast_file_system [2] Lion Kimbro, Cylinder Head Sector, 22.6.2206, http://en.wikipedia.org/wiki/image:cylinder_head_sector.s vg [3] Ing. Martin Bloch, CSc., Java, 22.6.2006, http://service.felk.cvut.cz/courses/x36pjv/slides/cesky/ [4] Ing. Božena Mannová, M.Math., Techniky testování softwaru, 22.6.2006, http://service.felk.cvut.cz/courses/x36rsf/prednasky/test ovani%20sw.ppt [5] Marshal Kirk McKusick, UFS2 Structure, 22.6.2006, http://ufs-linux.sourceforge.net/docs/ufs2.html [6] Peter Burden, The Unix File System, 22.6.2006, http://www.scit.wlv.ac.uk/~jphb/spos/notes/ufs.inode.html [7] Mark Kampe, Introduction to BSD UNIX Volume and File Structure, 22.6.2006, http://www.seas.ucla.edu/classes/mkampe/cs111.sq05/docs/b sd.html [8] Michele Larese, UFS File System Data Structures, 22.6.2006, http://www.x-ways.net/winhex/templates/index.html [9] Ing. Pavel Herout, Ph.D., JAVA - grafické uživatelské prostředí a čeština, 2001 [10] Bruce Eckel, Myslíme v jazyku Java, 2001 [11] Ing. Milan Drbohlav, Operační systém UNIX (1. díl) - Kompendium, 1998
34 KAPITOLA 7 SEZNAM POUŽITÉ LITERATURY
PŘÍLOHA A SEZNAM POUŽITÝCH ZKRATEK 35 A Seznam použitých zkratek BB CG DB GUI HW I-node I-uzel JRE OS SB SW UFS Boot Block, zaváděcí blok Cylinder Group, skupina válců Data Block, datový blok Graphical User Interface, grafické uživatelské prostředí HardWare, počítačové vybavení informační uzel informační uzel Java Runtime Environment, operační systém Super Block, superblok SowtWare, programové vybavení Unix File System, Unixový systém souborů
36 PŘÍLOHA A SEZNAM POUŽITÝCH ZKRATEK
PŘÍLOHA B UML DIAGRAMY 37 B UML diagramy Ilustrace 11: UML diagram třídy First
38 PŘÍLOHA B UML DIAGRAMY Ilustrace 12: UML diagram tříd Data, Inode, Dir Ilustrace 13: UML diagram třídy Settings
PŘÍLOHA B UML DIAGRAMY 39 Ilustrace 14: UML diagram metod třídy Data
40 PŘÍLOHA B UML DIAGRAMY Ilustrace 15: UML diagram třídy PlatnoBitMaps
PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA 41 C Uživatelská příručka C.1 Komu je applet výukový systém UFS určen Applet výukový systém UFS je určen široké veřejnosti, zejména pak těm, kteří se chtějí dozvědět trochu více ohledně UFS. C.2 adresa výukového systému UFS Applet je k dispozici na adrese: http://peter.apolon.cz/bc/ C.3 Systémové požadavky Pro provozování appletu je třeba mít k dispozici připojení na internet, novější prohlížeče Mozilla FireFox, Opera nebo InternetExplorer a nainstalovaný plug-in JRE. Applet se spouští v prohlížeči po načtení stránky z webové adresy. Applet je optimalizován pro rozlišení monitoru 800x600. C.4 Popis uživatelského rozhraní appletu C.4.1 Spuštění appletu Po spuštění appletu na klientském počítači v prohlížeči uživatele se zobrazí hláška (Ilustrace 16), která se uživatele zeptá, zda-li je pro něj applet důvěryhodný. Ilustrace 16: Uživatelská příručka - zobrazení ověřovacího certifikátu Pokud uživatel souhlasí s jeho důvěryhodností, nabízí applet možnost načítat soubory z klientského počítače. V opačném případě je tato možnost nepřístupná
42 PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA a tlačítko č.10 z ilustrace je neaktivní. Souhlasí-li s důvěryhodností appletu uživatel nebo nesouhlasí-li, načte se applet a zobrazí se úvodní obrazovka (Ilustrace 17). Ilustrace 17: Uživatelská příručka - úvodní obrazovka C.4.2 Úvodní obrazovka Úvodní obrazovka je obdobu Unixového terminálu. Uživatel může zadávat množinu příkazů viz. ilustrace 18, obdobných jako v Unixovém shellu. C.4.3 Nastavení systému Obrazovka je zobrazena na ilustraci 19 a její složení je následující: 1. pole pro vložení nové velikosti virtuálního disku. Možný rozsah je od 128kB do 4MB 2. výběr velikosti datového bloku. 3. tlačítko, které po stisknutí aplikuje veškeré změny na virtuálním disku. 4. tlačítko pro načtení externího souboru. Po stisknutí tohoto tlačítka se zobrazí dialogové okno výběru souboru viz. ilustrace 20. Takto vybraný soubor se uloží do kořenového adresáře / virtuálního disku. 5. informativní oblast, kam se zapisuje informace zdali si podařilo úspěšně načíst externí soubor.
PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA 43 Ilustrace 18: Uživatelská příručka - příkazy shellu 1 2 3 4 5 Ilustrace 19: Uživatelská příručka - nastavení systému
44 PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA Ilustrace 20: Uživatelská příručka - dialogové okno C.4.4 Grafické zobrazení UFS Tato část appletu nabízí vizuální zobrazení veškerých změn na virtuálním disku. Obrazovka je rozdělena na dvě části. Levou s tlačítky možných grafických stavů a pravou, kam se zobrazuje grafický výstup. viz. ilustrace 21. Ilustrace 21: Uživatelská příručka - grafický výstup - úvodní legenda
PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA 45 Možné grafické výstupy jsou označeny na ilustraci 22: 6. úvodní legenda grafického výstupu. Popisuje jak jsou rozvrženy jednotlivé části v UFS, co to je Sector, Track a Cylinder 7. zobrazení bitových map na disku. Tj. zobrazuje zaplněnost jednotlivých datových bloků. I-uzlů a fragmentovaných datových bloků viz ilustrace 23 na str.46 8. podrobná struktura I-uzlu. Klikne-li se na jednotlivé uzly, zobrazí se detailní datová struktura jednotlivých I-uzlů. viz. ilustrace 24na str.46 9. možnost podívat se na jednotlivé datové bloky viz. ilustrace 25na str.47. Obdobně jako u I-uzlů po kliknutí myši se zobrazí zdrojový DB tak, jak je uložen na disku viz. ilustrace 26 na str.47 7 9 6 8 Ilustrace 22: Uživatelská příručka - grafický výstup
46 PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA Ilustrace 23: Uživatelská příručka - grafický výstup - bitové mapy Ilustrace 24: Uživatelská příručka - grafický výstup - I-uzly
PŘÍLOHA C UŽIVATELSKÁ PŘÍRUČKA 47 Ilustrace 25: Uživatelská příručka - grafický výstup - datové bloky Ilustrace 26: Uživatelská příručka - grafický výstup - DB zdroj