Aleš Šnupárek Přenositelnost Systému Souborů Zlomekfs

Univerzita Karlova v Praze

Matematicko-fyzikální fakulta

DIPLOMOVÁ PRÁCE

Aleš Šnupárek

Přenositelnost systému souborů zlomekFS

Katedra distribuovaných a spolehlivých systémů

doc. Ing. Petr Tůma, Dr.

Studijní program: Informatika Studijní obor: softwarové systémy

Praha 2012

Na tomto místě bych chtěl poděkovat všem, bez jejichž pomoci by nikdy tato práce nevznikla. Mé díky patří zejména doc. Ing. Petru Tůmovi, Dr., za vedení diplomové práce, za dobré rady a věcné připomínky.

Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů, literatury a dalších odborných zdrojů.

Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona v platném znění, zejména skutečnost, že Univerzita Karlova v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 3. 8. 2012 Aleš Šnupárek

Název práce: Přenositelnost systému souborů zlomekFS

Autor: Aleš Šnupárek

Katedra: Katedra distribuovaných a spolehlivých systémů

Vedoucí diplomové práce: doc. Ing. Petr Tůma, Dr., Katedra distribuovaných a spolehlivých systémů

Abstrakt: ZlomekFS je distribuovaný souborový systém určený k transparentnímu sdílení adresářových stromů. Tato práce se zabývá možností portability souborového systému zlomekFS na jiný operační systém. V první části jsou popsány problémy, jež je nutné řešit k docílení portability programu. V části následující je zvažována možnost nasazení tohoto souborového systému na operační systém Android. Dále se tato práce zabývá portací zlomekFS na operační systém Windows. Poslední část obsahuje návod jak psát portabilní kód souborového systému. Klíčová slova: ZlomekFS, Dokan, Windows, Portabilita

Title: Portability in zlomekFS

Author: Aleš Šnupárek

Department: Department of Distributed and Dependable Systems

Supervisor: doc. Ing. Petr Tůma, Dr., Department of Distributed and Dependable Systems

Abstract: ZlomekFS is a distributed file system designed for transparent sharing of directory trees. This work deals with the possibility of portability zlomekFS to another operating system. The first section describes the problems that must be solved in order to achieve portability of the program. Subsequently, this work examines the possibility of deploying this file system on the Android operating system. Furthermore, this work deals with porting zlomekFS to the Windows operating system. The last section defines general guidelines for the file system code portability. Keywords: ZlomekFS, Dokan, Windows, Portability

Obsah

Úvod ...... 1

Cíle diplomové práce ...... 3

Struktura diplomové práce ...... 3

1 Přenositelnost ...... 1

1.1 Hardware...... 1

1.2 Operační systém ...... 2

1.3 Programovací jazyk ...... 4

1.4 Knihovna...... 5

1.5 Spustitelné programy ...... 7

1.6 Platforma ...... 8

1.7 Portace ...... 9

Překladový systém ...... 9

Docílení portability ...... 10

Portace řízená testy ...... 12

Simulace částí aplikace ...... 13

2 Souborový systém ...... 14

2.1 Název souborů, adresářů ...... 14

2.2 Speciální soubory ...... 15

2.3 Cesta k souboru...... 15

2.4 Přístupová práva k souboru ...... 16

2.5 Adresářová struktura ...... 17

2.6 Ostatní rozšíření souborového systému ...... 17

2.7 Userspace souborové systémy ...... 17

FUSE ...... 18

Dokan ...... 18

Jiné ...... 18

3 Standardy unixových operačních systémů ...... 20

3.1 POSIX ...... 20

3.2 Single Unix Specification ...... 22

3.3 Linux Standard Base ...... 22

4 Vybrané operační systémy ...... 23

4.1 Linux ...... 23

4.2 Android ...... 23

4.3 Mac OS X ...... 25

4.4 Windows ...... 25

Windows API ...... 25

Windows a POSIX ...... 26

4.5 Rozdíly mezi Windows a Linuxem ...... 28

Souborové API POSIX versus Win32 ...... 28

5 Popis zlomekFS ...... 31

5.1 Historie zlomekFS ...... 31

5.2 Platforma pro provozování zlomekFS ...... 32

5.3 Popis jednotlivých komponent ...... 32

6 Portace na Windows ...... 34

6.1 Stav zlomekFS před portací ...... 34

6.2 Úpravy provedené před portací zlomekFS ...... 36

Úpravy konfiguračních souborů ...... 38

Komunikační protokol mezi uzly ...... 39

6.3 Nasazení zlomekFS na Windows...... 41

6.4 Úpravy provedené během portace zlomekFS na Windows ...... 42

Windows FUSE ...... 43

Testování zlomekFS nad Win32 API ...... 44

6.5 Zhodnocení portu pro Windows ...... 44

6.6 Test rychlosti zlomekFS ...... 46

7 Portace na jiné operační systémy ...... 52

7.1 Android ...... 52

7.2 Mac OS X ...... 53

8 Přenositelnost zlomekFS na odlišné architektury procesoru ...... 54

9 Návod pro psaní portabilního kódu souborového systému ...... 56

9.1 Volba cílových platforem ...... 56

9.2 Volba jazyka a překladového systému ...... 56

9.3 Pravidla pro vytváření kódu ...... 56

9.4 Ladění a verifikace programu ...... 57

Závěr ...... 59

Seznam použité literatury ...... 61

Seznam tabulek ...... 63

Seznam použitých ilustrací ...... 64

Seznam použitých zkratek ...... 65

Přílohy ...... 66

A. Obsah CD-ROMu ...... 66

B. Porovnání vybraných souborových systémů ...... 67

C. Zprovoznění zlomekFS pod Windows ...... 69

D. Zprovoznění zlomekFS pod Androidem ve chrootu ...... 71

E. Překlad Wireshark dissectoru pro analýzu zlomekFS komunikačního protokolu ...... 72

F. ZlomekFS C Coding style ...... 73

Úvod Při práci s počítačem jsou vytvářena data, která jsou ukládána v datovém úložišti, například pevném disku. Tato data mohou být vytvářena, prohlížena, modifikována nebo mazána. Častým dalším požadavkem může být sdílení těchto dat s ostatními uživateli.

Přenos dat lze realizovat za pomoci výměnného média, například USB flash disku, nebo lze data poslat elektronickou poštou, přenést z FTP nebo z WWW sdílení. V případě dostatečné síťové konektivity mezi počítači uživatelů lze použít pro sdílení dat síťový souborový systém.

Obsah datového dokumentu muže být měněn. U některých dokumentů vyvstává potřeba možnosti přístupu ke starším verzím těchto dokumentů, než je aktuální verze. V případě této potřeby je nutné použít systém sledování změn (version controll system) nebo použít souborový systém s podporou verzování souborů.

Pokud je použito pro modifikaci stejného dokumentu více počítačů v síti, je potřeba zajistit, aby byla vždy upravována aktuální verze a provedené změny v dokumentu byly perzistentně uloženy.

Řešením všech výše uvedených problémů je použití buď speciálních programů, nebo souborového systému s patřičnými vlastnostmi. Mezi tyto souborové systémy patří zlomekFS. Jedná se o distribuovaný souborový systém s možností offline (disconnected) režimu. Jednotlivé uzly (node) tohoto systému jsou uspořádány do uživatelem definované stromové struktury. Díky offline režimu lze modifikovat soubory lokálně a při obnovení spojení s ostatními uzly se k nim propagují provedené změny. Posledním vylepšením souborového systému zlomekFS byla podpora pro verzování jednotlivých souborů. Díky výše uvedeným rysům je zlomekFS ideálním kandidátem pro nasazení síťového souborového systému.

V současném počítačovém světě se používají různé operační systémy. Ty jsou nasazeny v téměř každém zařízení obsahujícím procesor. Škála těchto zařízení sahá od embedded řešení přes mobilní telefony, stolní počítače, servery až

1 k superpočítačům. Pro tyto různé operační systémy vznikají aplikace, jejichž rozsah může být od pár desítek až ke stovkám tisíců řádek zdrojového kódu.

Libovolnou aplikaci lze provozovat pouze na počítačích s operačním systémem, pro nějž je tato aplikace určena. To může být omezujícím kritériem v případě potřeby nasadit nějakou aplikaci na širší spektrum počítačů s odlišnými operačními systémy. Může tedy vzniknout požadavek provozovat aplikaci pod jiným operačním systémem, než pod kterými byla dříve provozována.

Cíle diplomové práce ZlomekFS v současnosti lze provozovat pod operačním systémem Linux. Cílem je zmapovat a vyřešit problémy ve zlomekFS z hlediska portability. V této práci jsou řešeny následující problémy:

Nasazení zlomekFS na jinou platformu, než je operační systém Linux, změna vrstvy pro implementaci souborového systému v userspace, než je linuxová libfuse Prozkoumání portability zlomekFS na mobilním zařízení založeném na Linuxu, konkrétně na zařízení s operačním systémem Android Návod jak psát portabilní kód souborového systému

V rámci zadání diplomové práce byl požadavek na portaci zlomekFS na novější verzi FUSE. Řešení tohoto problému však bylo realizováno v rámci diplomové práce Rastislava Wartiaka: „History and Backup Support for zlomekFS“ [32], proto není v této práci tento požadavek řešen. Avšak byly opraveny některé nedostatky v integraci libfuse do zlomekFS.

Struktura diplomové práce Kapitola „Přenositelnost“ definuje pojem platformy a přenositelnosti a jsou zde popsány jednotlivé komponenty, které do platformy patří. V této kapitole je zaveden pojem „Portace“ a popsány problémy, které je nutné vyřešit k dosažení portabilního kódu. Kapitola „Souborový systém“ popisuje rozdíly jednotlivých souborových systémů z pohledu uživatele a popisuje různé knihovny pro implementaci souborového sytému v userspace. V kapitole „Standardy unixových operačních systémů“ je popsán vývoj a současný stav standardů operačního systému Unix. Kapitola „Vybrané operační systémy“ popisuje operační systémy vybrané k demonstraci problémů portace zlomekFS.

Kapitola „Popis zlomekFS“ popisuje historii zlomekFS, komponenty zlomekFS a platformu nutnou pro provozování zlomekFS.

Kapitola „Portace na Windows“ popisuje portaci zlomekFS na operační systém Windows.

Kapitola „Portace na jiné operační systémy“ popisuje možnost portace zlomekFS na mobilní operační systém Android. Dále se tato kapitola zabývá portací zlomekFS na Mac OS X.

V kapitole „Přenositelnost zlomekFS na odlišné architektury procesoru“ je zkoumána přenositelnost zlomekFS na odlišné architektury procesorů.

Kapitola „Návod pro psaní portabilního kódu souborového systému“ se zabývá psaním portabilního kódu souborového systému.

1 Přenositelnost Dříve než se vymezí pojem přenositelnosti, je nutné definovat pojmy, které jsou potřeba k definici přenositelnosti.

1.1 Hardware Základní komponentou počítače je procesor, vykonávající strojové instrukce, jež jsou kódovány v jeho strojovém kódu. Různé typy procesorů se od sebe liší různou instrukční sadou, šířkou, počtem a univerzálností registrů, počtem a vlastnostmi aritmeticko-logických jednotek (ALU).

Typ procesoru ovlivňuje portabilitu. Například počet a obecná použitelnost registrů ovlivňuje ABI (Application Binary Interface) vyšších programovacích jazyků. Šířka registrů ovlivňuje šířku některých datových typů (long, pointer) ve vyšších programovacích jazycích. Také ovlivňuje maximální velikost adresovatelné paměti procesorem.

Procesory se liší ve způsobu ukládání číselných typů do operační paměti. Nejpoužívanější jsou dvě varianty, Big-endian a Little-endian, také existuje historická varianta VAX-endian (1,3,4,2). Big-endian (4,3,2,1) ukládá do paměti na nejnižší adresu nejvíce významný byte (MSB), Little-endian (1,2,3,4) ukládá do paměti na nejnižší adresu nejméně významný byte (LSB).

Některé procesory při přístupu do paměti vyžadují zarovnání (alignment) elementárních datových typů, to znamená, že jsou schopny přistupovat pouze k datům, jejichž adresa je buď násobkem jejich délky, nebo jiné hardwarem definované konstanty. Velikost dostupné paměti v systému musí splňovat paměťové nároky příslušného programu.

Další rysy hardware, jako jsou například jednotka správy paměti nebo způsob připojení konkrétních periferií, nemají z hlediska portability aplikace většinou vliv, protože jsou zcela vždy odstíněny operačním systémem. Naopak při portaci operačního systému je třeba všechny tyto vlastnosti brát v potaz.

Další hardwarové komponenty jsou připojeny k procesoru přes sběrnice. Abstrahujeme-li od detailů funkce chipsetu, můžeme sběrnice rozdělit na

1 sběrnici připojující paměť a na sběrnice, které připojují periferie, například sériový port, řadič USB nebo pevný disk.

Pro potřebu této práce lze hardware zjednodušeně chápat jako sběrnicemi propojený procesor, paměť a periferie.

Závislost aplikace na hardware je daná oblastí, do které tato aplikace patří. Například závislost ovladače periferie na hardware je velmi vysoká. Bude-li se jednat o jednoduchý webový server, je závislost na konkrétním hardware minimální. V tomto případě potřebnou abstrakci zajišťuje operační systém.

1.2 Operační systém Operační systém je základní softwarové vybavení počítače. Je instalován na téměř každém počítači. Ačkoliv existuje větší množství různých operačních systémů, jejich základní funkcionalita je shodná. Různé operační systémy používají často stejné algoritmy pro řešení stejných problémů.

V první řadě je cílem operačního systému je spouštět uživatelské aplikace a umožňovat jejich komunikaci s okolím. Další funkcí operačního systému je správa a přidělování prostředků (procesor, paměť, periferie) těmto aplikacím, oddělení procesů od sebe, implementace synchronizačních primitiv a přístup k periferiím a souborům. Rozhraní, přes které komunikuje aplikace s operačním systémem, se nazývá systémové API (Application Programming Interface) operačního systému. Existuje několik norem, které toto API definují, například SVID, XOPEN, SUS, POSIX, Win32. API většiny operačních systémů se vždy snaží být kompatibilní s některými z těchto norem. Ale existuje řada experimentálních operačních systémů, jejichž API není specifikováno žádnou normou. Mezi ně patří například HelenOS.

Během života operačního systému vznikají požadavky na jeho změny. Může se jednat o podporu nového typu hardware (např. podpora USB) nebo může být tento systém rozšířen o novou komponentu (např. bezpečnostní subsystém). Tyto změny se mohou promítnout i do změn systémového API, jež může být během vývoje operačního systému rozšířeno, případně pozměněno.

Pro programátora je operační systém zajímavý svým API, které bývá definováno jako rozhraní systémových knihoven. Toto rozhraní je používáno uživatelskými programy pro přístup ke službám operačního systému. Systémové knihovny mohou odstínit změny provedené v nižších vrstvách operačního systému.

Různé operační systémy se od sebe vzájemně liší ve svých systémových API. To znamená, že pro řešení obdobných problémů se v nich používají různé posloupnosti volání funkcí systémových knihoven. Proto patří operační systém do platformy.

1.3 Programovací jazyk Algoritmy programu jsou popsány v programovacích jazycích. Ty lze rozdělit dle způsobu překladu do tří základních skupin dle způsobu překladu: jazyky překládané přímo do strojového kódu příslušného procesoru, jazyky překládané do přenositelného metajazyka (byte kód) a jazyky interpretované (často též překládané při běhu do metajazyka).

Jazyky překládané do strojového kódu jsou nejvíce svázány s konkrétním procesorem. Liší se různou délkou konkrétních datových typů (long, pointer), uspořádáním bytů v paměti (endianitou), zarovnáním datových typů v paměti (alignmentem), a to vše v závislosti na konkrétním procesoru. Další odlišnost mezi různými procesory (i různými systémy a překladači) je volací konvence podprogramů (ABI). Příkladem programovacích jazyků překládaných do strojového kódu jsou C, C++, Fortran a Pascal.

Pro běh programů napsaných v jazycích překládaných do metajazyka se používá virtuální stroj, který zaručuje stejnou šířku datových typů a eliminuje problém s endianitou na různých procesorech. Do této skupiny jazyků patří Java a C#.

Datové typy interpretovaných jazyků bývají většinou nezávislé na konkrétním operačním systému i cílovém procesoru.

Během života samotného programovacího jazyka může docházet k jeho rozšíření o novou funkcionalitu. Toto nové rozšíření nemusí být zpětně kompatibilní s programy, které byly vytvořeny ve starší verzi tohoto jazyka. Pokud existuje více překladačů konkrétního jazyka od několika různých dodavatelů, může se stát, že program přeložitelný jednou verzí překladače nelze přeložit v druhé verzi.

Pro některé programovací jazyky existují normy, které je specifikují. Například jazyk C má několik norem: K&R, ANSI C, C89, C99. Tyto normy nejsou mezi sebou vzájemně kompatibilní, některé z nich nemusí být implementovány v konkrétním překladači, nebo se tato implementace může lišit v závislosti na konkrétním překladači. Některé překladače obsahují rozšíření, které nemusí být v jiných překladačích dostupné.

1.4 Knihovna Knihovna sdružuje části kódu implementujícího skupinu souvisejících algoritmů do jednoho logického celku. Příkladem může být knihovna pro práci s konkrétním obrázkovým formátem (libpng) nebo knihovny pro implementaci kryptografických algoritmů (OpenSSL). Po oddělení části programu do knihovny je možné používat kód z této knihovny v ostatních programech.

Soubor funkcí, které knihovna veřejně publikuje, je specifikován v API této knihovny. Během života konkrétní knihovny může vzniknout požadavek na rozšíření, případně změnu funkcionality některých podprogramů obsažených v knihovně nebo přidání nových podprogramů. Tyto změny se projeví i změnou API této knihovny. V případě změny některého podprogramu, který se promítne do změny API, je porušena kompatibilita nové knihovny s knihovnou původní, a je proto třeba tuto změnu promítnout i do všech programů využívajících tuto knihovnu. Méně kritická je situace při rozšíření API. V tom případě stačí zajistit, aby nová knihovna nebyla zaměněna za starou, která z pohledu programu slinkovaného s novou knihovnou neobsahuje všechny potřebné podprogramy. Proto jsou v mnoha operačních systémech knihovny verzovány.

Na některých operačních systémech (Solaris, Linux) byla původně ke každé sdílené knihovně přiřazena právě dvě verzová čísla, tzv. major a minor. Major bylo zvykem inkrementovat při nekompatibilní změně API, v tom případě se minor nastavoval na nulu. Minor bylo zvykem inkrementovat při kompatibilním rozšíření API. To dnes už bohužel obecně neplatí. Knihovny v současnosti mívají od jednoho do čtyřech verzových čísel. U některých knihoven se jejich verze dokonce skládá z posloupnosti alfanumerických řetězců. Verze většinou bývá měněna při změně kódu.

Pokud je aplikace spuštěna s jinou verzí knihovny, než s jakou byla slinkována, dochází při použití změněného nebo neexistujícího podprogramu k náhodné chybě, která se nemusí projevit, může změnit chování aplikace a může způsobit i její pád. Většina operačních systémů má logiku, která hlídá verze knihoven v případě klasicky přilinkovaných knihoven. V případě dynamicky zaváděných

5 knihoven je hlídání verzí čistě na autorovi programu. Identifikovat tento druh chyby v programu bývá v některých případech velmi těžké.

Portabilitu aplikace ovlivňuje dostupnost příslušných verzí knihoven, které jsou nutné pro běh aplikace v cílovém operačním systému.

Pro samotnou knihovnu platí obdobná pravidla jako pro aplikaci. Její nasazení může být omezeno na konkrétní typy, případně verze operačních systémů. Pokud bude část kódu knihovny napsaná v assembleru, pak tato knihovna bude funkční pouze na konkrétním typu procesoru.

Funkcionalita knihovny se může lišit v závislosti na operačním systému, na kterém je tato knihovna provozována. Například popis cesty k souboru je odlišný v prostředí různých operačních systémů. Některé na operačním systému závislé funkcionality v knihovně nemusí být implementovány pro konkrétní operační systém.

Pro některé typy knihoven existuje více různých implementací, například pro Linux existují minimálně dvě různé implementace standardní knihovny jazyka C, glibc a uClibc. Tyto knihovny implementují funkcionalitu, která je daná normou, ale také mohou obsahovat vzájemně nekompatibilní rozšíření. Pokud budeme požadovat od programu portabilitu mezi různými knihovnami libc, nesmíme používat jejich nestandardní rozšíření.

Ve dvou různých operačních systémech mohou být API systémových knihoven vzájemně odlišná. Existují knihovny, které abstrahují funkcionalitu operačního systému, čímž zjednodušují portace mezi různými operačními systémy. Mezi takové knihovny patří například glib2 pro C a libboost pro C++. Příkladem takto unifikované funkcionality je abstrakce pro podporu vláken.

1.5 Spustitelné programy Binární formát programu se až na několik výjimek skládá z hlavičky (hlaviček), metadat a vlastních binárních dat. V hlavičkách je standardním způsobem zaznamenáno, jak nakládat s programovými daty, než jim je předáno řízení. Metadata mohou mimo jiné obsahovat příkazy k relokaci. Podle nich jsou upravena data v paměti před spuštěním. Relokace se nemusí používat u kódu, který je pozičně invariantní (PIC). Vytvoření pozičně invariantního kódu je jedna z funkcí kompilátoru. Od strojového kódu procesoru se odvíjí cena za tuto vlastnost.

Existují typy procesorů, jejichž přirozený kód je invariantní, a existují typy procesorů, pro něž pozičně invariantní kód vytvořit nelze. Všechny dostupné procesory lze klasifikovat v rozmezí těchto hranic.

Formát hlaviček binárního souboru většinou odpovídá některému z rozšířených formátů. Historický A.OUT se dnes již nepoužívá. Jeho nástupce COFF se dodnes používá ve verzi ECOFF v AIXu. Jiným rozšířením COFF/PE je binární formát v systémech Microsoft Windows. Dnes nejrozšířenější formát hlaviček ELF se používá ve většině unixových systémů včetně Linuxu. Podobný ELF formátu je Mach-O, který se používá v MacOS X.

Dalším faktorem ovlivňujícím běh programu je způsob linkování (staticky, nebo dynamicky). Staticky slinkovaný program zaujímá větší místo v operační paměti, ale je odolnější proti porušení integrity systému. Proto se v některých operačních systémech (BSD) linkují základní systémové utility staticky. Dynamicky linkované programy potřebují ke svému běhu dynamické knihovny, s nimiž byly slinkovány. Systém tyto knihovny zavádí do paměti spolu s binárním programem při jeho spuštění. Dynamicky linkované programy sdílejí mezi sebou dynamické knihovny, a to tím způsobem, že spustitelný kód každé dynamické knihovny je umístěn ve virtuální paměti právě jednou. Některé programy vyžadují dynamické zavádění podprogramů například zásuvných modulů za běhu. Tato vlastnost může zkomplikovat portaci těchto programů.

1.6 Platforma Platforma dané aplikace definuje nezbytné prostředky, které tato aplikace potřebuje ke své plné funkčnosti. V případě jádra operačního systému jsou jeho platformou vlastnosti hardware, na kterém toto jádro běží. Samotné jádro operačního systému spolu s některými vlastnostmi hardware definuje platformu pro základní systémové knihovny. Jedná se o ty vlastnosti hardware, které nemůže jádro operačního systému abstrahovat, kupříkladu to jsou vlastnosti použitého procesoru, a tedy patří do platformy systémových knihoven.

Platformu aplikace silně ovlivňuje zvolený programovací jazyk. Programy psané v jazyku překládaném do strojového kódu procesoru budou na tomto strojovém kódu závislé. Programy psané v interpretovaných jazycích na strojovém kódu obvykle závislé nebývají. Zvláštní skupinou programovacích jazyků jsou jazyky překládající zdrojový kód do instrukčního kódu virtuálního stroje. Portabilita programů napsaných v těchto jazycích je závislá na portabilitě samotného virtuálního stroje.

Do platformy uživatelských programů napsaných v jazycích, které se překládají do strojového kódu, patří některé vlastnosti hardware a některé vlastnosti operačního systému, jak bylo zmíněno výše. Kromě toho do platformy patří některé vlastnosti použitých knihoven a různá systémová nastavení.

Závislost programu na operačním systému (případně na hardware) lze částečně, v ideálním případě úplně, eliminovat vhodnou volbou programovacího jazyka. Příkladem může být jazyk Java, který je překládaný do byte kódu pro virtuální stroj. Tento stroj do značné míry odstraňuje závislost na operačním systému a úplně ruší závislost na použitém procesoru.

Do platformy spadají vlastnosti z následujícího seznamu:

hardware (CPU, architektura) operační systém (typ, verze, případně jeho konfigurace) programovací jazyk nástroje nutné pro překlad a běh programu

knihovny nutné pro běh programu nastavení prostředí operačního systému

1.7 Portace Přenositelnost (portabilita) softwarového díla znamená možnost nasazení tohoto programu na jinou platformu, než pro kterou byl primárně vytvořen.

Portace je posloupnost úkonů, které je potřeba vykonat, aby bylo možné nasadit aplikaci na novou platformu. Při tom vznikají problémy, které je nutné během této portace překonávat. Řešení těchto problémů se projeví v úpravách zdrojového kódu aplikace. Z důvodu portability je potřeba vyřešit úpravy samotného programu, úpravy překladového systému nebo doplnění programu o testy, které ověřují jeho funkcionalitu na nové platformě.

Nejjednodušším příkladem portace aplikace je aktualizace jejího kódu, aby byla schopna pracovat s jinou verzí knihovny, než se kterou se běžně používá. Příkladem portace operačního systému je jeho přizpůsobení na novou architekturu procesoru.

Překladový systém Překladový systém (build system) slouží k překladu programu ze zdrojových kódů do spustitelné formy. Dalším úkolem tohoto systému je ověření, zda cílová platforma splňuje všechny požadavky pro překlad a běh programu. Během tohoto ověřování je zkoumán překladač a jeho verze, pomocné nástroje nutné pro překlad, případně jejich verze, knihovny nutné pro běh programu, případně jejich verze. Dále by měl překladový systém umožnit zvolit překlad aplikace pro ladění nebo pro produkční prostředí.

Klasickým příkladem ze světa GNU je konfigurace překladu za pomoci skriptu configure a překlad programu příkazem make. Mnoho aplikací (nejen z GNU projektu) je distribuována s tímto překladovým systémem. Nejprve se spustí skript configure, jež vygeneruje Makefile, na který se potom spustí program make.

Napsat ručně configure pro složitější program nemusí být nejjednodušší. Proto vznikly autotools, programový balík, jehož úkolem je zjednodušit vytváření

9 build systému. Tato sada nástrojů je postavena na makroprocesoru M4. V tomto jazyce se popíše, jak budou vypadat soubory configure a Makefile a autotools je na základě těchto popisů vygeneruje.

Vzhledem k tomu, že autotools jsou velmi komplexní, jejich použití nemusí být vždy nejjednodušší, proto vznikla moderní alternativa tohoto nástroje, CMake.

Docílení portability Před portací programu na novou platformu je vhodné ověřit, zda pro novou platformu existuje překladač jazyka, v němž je příslušný program napsán. V ideálním případě na cílové platformě existuje překladač od stejného výrobce a ve stejné verzi jako na původní platformě. Pokud pro cílovou platformu existuje pouze překladač od jiného dodavatele, je třeba v prvním kroku upravit zdrojové kódy tak, aby byly přeložitelné oběma překladači. Práci nám může ulehčit existence verze překladače pro starou platformu totožná s verzí překladače pro novou platformu. Pro psaní přenositelného kódu mezi překladači je třeba používat pouze konstrukce, které specifikuje obecná norma jazyka, a vyhnout se všem nekompatibilním rozšířením příslušné implementace překladače.

Dalším problémem mohou být stejné typy knihoven, které pocházejí od různých výrobců. Příkladem této knihovny je základní knihovna jazyka C, libc, od níž existuje více implementací, mj. GNU libc, uClibc nebo BSD libc. Z hlediska portability zde platí stejné pravidlo jako pro překladač: nepoužívat nekompatibilní rozšíření. Pokud je potřeba použít v kódu nekompatibilní rozšíření, je vhodné implementovat ve vlastním kódu ekvivalent tohoto rozšíření pro platformy, kde toto rozšíření není dostupné. Tato rozšíření jsou obvykle sdružována do dedikované separátní knihovny, jejíž překlad a komponenty jsou závislé na konkrétní platformě. Další variantou v jazyce C je použití podmíněného překladu. Dle mého názoru je použití samostatné knihovny vhodnější řešení.

V případě nízko úrovňových programovacích jazyků je potřeba mít datový typ příslušného rozsahu. V tomto případě je dobré použít definici na základě cílové platformy a nespoléhat na šířky základních datových typů příslušného

10 programovacího jazyka. Pro jazyk C existuje definice celočíselných typů, které nejsou závislé na cílové platformě v include souboru .

Existuje-li možnost, že by měla aplikace komunikovat se svým protějškem přes síť, nebo existuje-li potřeba sdílet data mezi aplikacemi na různých platformách, stojí za zvážení, v jakém formátu si budou aplikace data vyměňovat. Existují dvě varianty - použít binární data, nebo použít textová data. Pokud si budou aplikace vyměňovat data v binární podobě, je potřeba zajistit, aby existovaly na obou platformách typy, do nichž lze tato data načíst. Dále je potřeba dát pozor na endianitu dat, případně při načítání dat na jejich zarovnání v paměti. Pokud budeme předávat data v textové podobě, vyhneme se problémům s endianitou a zarovnáním dat v paměti. Na druhou stranu můžeme mít problémy s kódováním vyměňovaných dat nebo s nekompatibilitou formátu dat způsobenou národním nastavením. Další potencionální problém může být v oddělovačích jednotlivých řádek, Windows používá posloupnost dvou znaků (cr, lf), UNIX-like systémy jeden znak (lf) a Mac OS před verzí 10 používal jeden znak (cr). Binární data pro výměnu informací jsou úspornější co do velikosti a dají se rychleji zpracovat. Výhodou dat v textové podobě je jejich vyšší odolnost při serializaci a deserializaci. Přenos čísel s plovoucí čárkou v binární podobě může být mezi různými platformami velmi těžko realizovatelný, neboť na různých platformách mohou mít tato čísla různý formát daný hardwarem FPU. Konverzí těchto čísel na textovou podobu se těmto problémům vyhneme.

Je rozumné oddělit implementaci částí kódu závislých na platformě od částí kódu na platformě nezávislých. Příkladem takto strukturovaného zdrojového kódu je zdrojový kód linuxového jádra. Zde jsou platformě závislé zdrojové kódy umístěné v podadresářích adresáře ./arch/, pojmenovaných podle názvu platformy.

Vhodné použití komplexního překladového systému může zlepšit přenositelnost programu. Prvním důvodem je konfigurace překladu v závislosti na cílové platformě. Druhým je dostupnost standardních cílů programu make: make, make install nebo make clean. Během ruční implementace těchto cílů můžeme některý z nich špatně implementovat, což může způsobit nekompatibilitu našeho překladového systému s nástrojem pro tvorbu balíčků (rmp, deb,

11 portage nebo ports) v některém operačním systému. Díky tomuto systému lze specifikovat, jak bude program přeložen či jaké moduly se budou překládat.

Dodržování programovacích konvencí v rámci celého projektu přispěje výrazně k jednodušší orientaci v kódu, a tedy může ušetřit práci nutnou pro portaci programu na novou platformu. Orientaci ve zdrojových kódech zjednodušuje jejich rozdělení do logických celků. Rozsetí platformě závislých částí kódů v celém zdrojovém kódu programu výrazně komplikuje portaci programu.

Portace řízená testy Před započetím práce, která je nutná pro přenos programu na novou platformu, je dobré ověřit, že program funguje na staré platformě bezchybně. Pro tento účel se hodí sada testů. Může se jednat o unit testy, které ověřují funkcionalitu jednotlivých komponent, nebo integrační testy, jež ověřují funkčnost mezi několika komponentami. V poslední řadě se může jednat o komplexní testy, které ověřují celkovou funkcionalitu programu.

V první fázi se spustí testy na staré platformě a ověří se, že se všechny testy dokončí bezchybně. Pak se stejná sada testů spustí na nové platformě, ukončí-li se některé testy s chybou, je nutné tuto chybu opravit a zopakovat testy. Pokud žádný test neskončí s chybou, je portování úspěšně dokončeno.

Je potřeba doplnit všechny potřebné testy, nejsou-li již v programu přítomny. V případě, že se na nové platformě objeví neočekávaná chyba, která není detekována stávajícími testy, je vhodné napsat co nejjednodušší test, který tuto chybu reprodukuje. Proběhne-li tento test na staré platformě v pořádku, jedná se pravděpodobně o chybu vzniklou během portace. Jestliže musíme v rámci přenosu aplikace napsat novou komponentu, která abstrahuje některé z funkcionalit specifických pro novou platformu, je dobré doplnit testy, které ověřují funkčnost interface této komponenty. Pokud nová komponenta nahrazuje komponentu ze staré platformy, můžou se tyto testy spouštět i na staré platformě. Výsledky testů budou ověřovat možnost vzájemné záměny staré a nové komponenty.

Simulace částí aplikace Je-li potřeba nasadit aplikaci, u které je nutné pro zprovoznění na nové platformě naimplementovat znovu jednu z jejích komponent, vyplatí se vytvořit simulátor zbývající části aplikace pro lepší otestování funkčnosti nově implementované komponenty.

Tento simulátor můžeme realizovat tak, že na původní platformě spustíme aplikaci a logujeme komunikaci mezi komponentou, kterou potřebujeme nově implementovat, a zbylou částí systému. Na základě těchto logů vytvoříme simulátor pro nově implementovanou komponentu.

2 Souborový systém Souborový systém je označení způsobu organizace dat ve formě souborů, případně adresářů tak, aby k nim bylo možné snadno přistupovat. Souborové systémy mohou být uloženy na vhodném typu elektronické paměti, která je umístěna přímo v počítači nebo dočasně s počítačem propojena. Příklady lokálních uložišť souborových systémů jsou pevný disk, výměnný disk nebo CD. Souborové systémy také můžou být zpřístupněny pomocí počítačové sítě.

Souborový systém kromě souborů a adresářů musí uchovávat doplňující informace o těchto entitách. Tyto informace se nazývají metadata. Mezi ně patří název souboru nebo adresáře případně datum poslední modifikace. Další metadata (jako jsou práva pro přístup k danému objektu nebo údaje o vlastníkovi souboru) jsou zpravidla různě implementována v závislosti na konkrétním souborovém systému a také na použitém operačním systému.

2.1 Název souborů, adresářů Název souborů je jednoznačný identifikátor složený z posloupnosti znaků. Omezení pro tento identifikátor jsou různá v závislosti na souborovém systému nebo na operačním systému. Mezi tato omezení muže patřit kódování abecedy, množina dovolených nebo zakázaných znaků, případně délka jména souboru. Dále mohou být rezervována klíčová slova, která nesmí být použita v názvu souboru nebo adresáře.

Velmi častým rozdílem v souborových systémech bývá rozlišení velkých a malých písmen. Operační systém může považovat velká a malá písmena za identická, nebo je rozlišovat. Souborový systém může u názvů zachovávat velká a malá písmena, nebo může malá písmena konvertovat na velká, čímž je informace o velkých a malých písmenech ztracena. Pro názvy souborů v souborovém systému následující pravidla:

Maximální délka jména souboru Rezervované znaky, které se nemohou v názvu souboru vyskytovat {/, \, ?, %, *, :, |, <, >, .}. Kódování abecedy: o ASCII

o CP 1250 o EBCDIC o UCS-2 o UTF-8 o UTF-16 o a jiné

V operačním systému Windows se původně používala směs několika kódování: UCS-2, ASCII a CP*****, kde číslo kódové stránky odpovídalo národnímu nastavení operačního systému. Od Windows verze 2000 se používá UTF-16 místo UCS-2. Většina linuxových distribucí dnes standardně používá UTF-8 namísto původního ASCII.

Tabulka porovnávající přípustné názvy souborů v jednotlivých souborových systémech se nachází v příloze „Porovnání vybraných souborových systémů“.

2.2 Speciální soubory V souborových systémech mohou být uloženy speciální soubory, které mohou sloužit ke komunikaci s operačním systémem nebo pro komunikaci mezi procesy. Jedná se například o device file, sockety, pojmenované roury nebo doors. Funkcionalita těchto speciálních souborů je implementována většinou v operačním systému. S těmito soubory nelze pracovat mezi více počítači, které je sdílejí mezi sebou za pomoci síťového souborového systému.

Mezi speciální soubory patří různé druhy linků, například symbolické linky nebo shortcuts (inteligentní symbolické linky). Hardlinky, známé z unixových operačních systémů, nepatří mezi speciální soubory, jedná se o různá pojmenování stejného inode. Dva různé soubory, které se odkazují na stejný inode, jsou z hlediska operačního systému rovnocenné.

2.3 Cesta k souboru Cesta k souboru je řetězec, jenž jednoznačně identifikuje soubor. Tato cesta může být absolutní, tedy nezávislá na aktuálním pracovním adresáři, nebo může být relativní k aktuálnímu pracovnímu adresáři.

Úplná cesta k souboru v hierarchickém souborovém systému je složena z posloupnosti názvů adresářů a souboru, které jsou vzájemně odděleny oddělovačem. Tento oddělovač se liší v závislosti na operačním systému: ve Windows „\“ a v unixových operačních systémech „/“. Ve VMS jsou podadresáře odděleny znakem „.“, celá adresářová část cesty je uzavřena do hranatých závorek.

V některých operačních systémech může cesta k souboru obsahovat entity specifické pro příslušný operační systém, jako je jméno svazku v operačním systému Windows nebo verze souboru ve VMS.

V některých operačních systémech jsou implementovány specifické řetězce se speciálním významem. Jedná se například o odkaz na aktuální nebo nadřazený adresář. V unixových systémech a Windows je tento řetězec pro aktuální adresář „.“ a pro nadřazený adresář „..“. Operační systém VMS řetězce pro aktuální a nadřazený adresář neimplementuje.

2.4 Přístupová práva k souboru Ve víceuživatelských systémech je třeba oddělit uživatele od sebe včetně jejich dat. Řešením je definovat přístupová práva k souborům. Během vývoje těchto operačních systémů vzniklo mnoho různých implementací mechanizmu přístupových práv.

Systémy odvozené od UNIXu implementují tři práva: právo pro čtení, právo pro zápis a právo pro spuštění souboru (u adresáře znamená právo k přístupu k informacím o souborech v tomto adresáři). Dále se u každého souboru ukládá číslo vlastníka a číslo skupiny. Výše zmíněná přístupová práva se definují zvlášť pro vlastníka, skupinu a ostatní. Přístupová práva se vyhodnocují následovně: Pokud k souboru přistupuje jeho vlastník, má práva pro vlastníka, bude-li přistupovat člen skupiny, která je uvedena u souboru, dostane práva skupiny. Pokud ten, kdo přistupuje k souboru, není ani členem skupiny, ani vlastníkem, dostane práva pro ostatní.

Podobně jako v UNIXu jsou přístupová práva řešena ve VMS, V tomto OS jsou unixová tři práva rozšířena o čtvrté: právo smazat soubor. Tři přístupové skupiny jsou zde doplněny o další přístupovou skupinu - „system“.

S přístupovými právy skupiny „system“ přistupují k souborům interní systémové procesy.

Jinou variantou jsou práva na úrovni ACL (access lists), kdy ke každému souboru nebo adresáři je připojen seznam dvojic: uživatel a jeho práva k příslušnému souboru. Tento model přístupových práv je implementován v systému Windows. Ve Windows jsou rozeznávána ACL u souborů i adresářů. Konkrétně se jedná o právo pro přístup k adresáři, o právo čtení, o právu zápisu nebo smazání souboru a o právo na změnu přístupových práv.

V některých unixových systémech rozšiřuje ACL model klasická unixová práva, pro každého uživatele lze pomocí ACL nastavit tři základní unixová práva.

Zajímavá jsou přístupová práva na síťovém souborovém systému AFS. Tato práva jsou založena na ACL modelu, ale jednotlivá ACL práva jsou přiřazena jen k adresářům. Přístupová práva všech souborů v adresáři se řídí ACL tohoto adresáře. Jsou rozlišována tato práva: čtení, zápis, čtení informací o souborech v adresáři, vytvoření souboru, smazání souboru, zamčení souboru, právo modifikovat ACL. Tato práva jsou v UNIX kompatibilním módu doplněna o klasická unixová práva, jež se vztahují na jednotlivé soubory.

2.5 Adresářová struktura Většina dnes používaných souborových systémů umožňuje organizovat adresáře do stromové struktury. Během evoluce souborových systémů tomu tak nebylo. Příkladem stromově nestrukturovaného souborového systému je MFS (Macintosh File System), sestávající se z jednoho adresáře s možností vytvářet pouze soubory. Takový souborový systém se nazývá „nestrukturovaný souborový systém“.

2.6 Ostatní rozšíření souborového systému Některé souborové systémy obsahují různá rozšíření, která jsou typická pouze pro ně. Jmenujme například pojmenované streamy v NFTS.

2.7 Userspace souborové systémy V běžných operačních systémech jsou souborové systémy implementovány přímo v kernelu. V posledních letech se prosazují implementace nestandardních

17 souborových systémů v userspace. Jejich implementace je většinou realizována kernelovým ovladačem a userspace procesem, mezi nimiž probíhá komunikace. Samotná implementace souborového systému je napsána jako aplikace, která běží v userspace.

Jako userspace souborový systém je implementováno například SSHFS nebo souborový systém s podporou šifrování (CFS). Mezi výhody tohoto přístupu patří širší výběr knihoven, jednodušší ladění programu, také odpadá komunikace s vývojáři kernelu. Pokud je kernelový interface dobře navržen, nezpůsobí případný pád souborového systému pád kernelu. Na druhou stranu userspace řešení může mít negativní vliv na výkon nebo může být v některých případech velmi složité, zvláště když narazí na omezení komunikačního protokolu mezi kernelovou a userspace částí.

FUSE File system in userspace (FUSE) je knihovna pro implementaci souborového systému pro userspace pro systémy Linux, FreeBSD, OpenSolaris a Mac OS X. API této knihovny je inspirováno unixovým API pro práci se soubory.

Dokan Dokan [2] (v jap. „hliněná dýmka“) je implementace FUSE pro Windows. Jedná se o Open Source projekt japonského autora Hirokiho Asakawy. Projekt Dokan lze nalézt na url http://dokan-dev.net/en.

Jeho rozhraní je navrženo s ohledem na Win32 API. Skládá se z kernelového ovladače a userspace knihovny. V rámci tohoto projektu vznikla ukázková implementace souborového systému mirror, který vyexportuje libovolný zvolený adresář jako souborový systém. Dále existuje také podpora pro jazyk C#, ve kterém je napsáno SSHFS.

Vzhledem k tomu, že se jedná o relativně mladý projekt, je pravděpodobné, že v něm budou nějaké nedostatky. Na druhou stranu se jedná o ideální FUSE Framework s odlišným API, na kterém se dá ověřit portabilita zlomekFS.

Jiné K vytvoření souborového systému v userspace je možno použít jiné knihovny, než byly výše uvedeny. Souborový systém je možné zaintegrovat do operačního

18 systému jako server síťového souborového systému. Tento přístup používá CFS [21], který jako komunikační protokol používá NFSv2. Jiny přístup používá implementace souborového systému AFS arla [22], ta používá vlastní kernelový ovladač s vlastním komunikačním rozhraním.

3 Standardy unixových operačních systémů Během prvního desetiletí existence operačního systému UNIX vzniklo několik variant původního AT&T UNIXu. Byly rozšířeny o různá systémová volání, byly doplněny o nové programy a o nové démony. Ovládání standardních unixových programů se lišilo v závislosti na konkrétní implementaci UNIXu. Ve snaze sjednotit chování těchto implementací vznikla řada standardů, mezi něž patří SVID, X/Open, POSIX a SUS.

3.1 POSIX POSIX (Portable Operating Systém Interface) je označení standardů, které jsou především dodržovány v unixových operačních systémech. Cílem těchto standardů je definice jednotného rozhraní, které zajišťuje přenositelnost aplikací mezi různými hardwarovými nebo softwarovými platformami. Standard definuje z pohledu programátora hlavičkové soubory, systémová volání a knihovní funkce. Z pohledu systémového administrátora do standardu patří seznam programů a popis jejich chování.

POSIX byl původně definován standardem IEEE 1003.1-1988 z roku 1988. Norma POSIX.1 byla popsaná v IEEE Std 1003.1-1988, definovala základní služby operačního systému a zahrnovala v sobě specifikaci standardu ANSI C. Tento standard v sobě zahrnoval definice pro:

Vytváření a správu procesů Signály: o Způsobené chybou při výpočtu s plovoucí řádovou čárkou o Způsobené neplatným mapováním paměti o Způsobené porušením ochrany paměti o Způsobené použitím neexistující instrukce o Způsobené použitím privilegované instrukce v neprivilegovaném režimu procesoru o Ostatní (časovače atd.) Vstupně výstupní operace o Operace se soubory a adresáři o Operace s rourami

o Operace s periferiemi Operace pro správu prostředků procesů

Norma POSIX.1b doplnila standard o real-time funkcionalitu, byla popsaná v IEEE Std 1003.1b-1993. Norma specifikovala následující funkcionalitu:

o Plánování priorit o Real-time signály o Hodiny a časovače o Asynchronní a synchronní I/O o Interface pro zamykání paměti o Zasílání zpráv o Semafory o Sdílená paměť

Norma POSIX.1c rozšířila standard o podporu vláken, byla popsána v IEE Std 1003.1c-1995. Norma specifikovala následující funkcionalitu:

o Vytvoření, řízení a rušení vláken o Plánování vláken o Synchronizace vláken o Zpracování signálů ve vláknech

Norma POSIX. 2 rozšířila standard o shell a nástroje, byla popsaná v IEEE Std 1003.2-1992. Obsahuje popis:

o Shell (Korn shell) o utility

Další norma POSIXu jePOSIX.1-2001, která nově specifikovala práci se sokety. Tato norma revidovala předcházející verze POSIXu. Je základem SUS verze 3. V současné době je nejnovější verze POSIX.1-2008 specifikovaná normou IEEE Std 1003.1-2008, která je revizí POSIX.1-2001.

V různých operačních systémech se rozsah implementace POSIX standardu značně odlišuje. Mezi systémy, které plně implementují POSIX, patří Mac OS X. Velká část POSIX standardu je implementována v Linuxu a v FreeBSD. Microsoft

21 implementoval POSIX 1 standard ve starších verzích Windows NT. V novějších verzích Windows je podpora aktuálnějších POSIX standardů ze strany Microsoftu zajištěna subsystémem Interix.

3.2 Single Unix Specification Single Unix Specification (SUS) je standard operačních systémů UNIX. SUS byl navržen a je dále udržován společností Austin Group. SUS navazuje na předchozí standardy, mezi které patří POSIX, SVID a X/Open. Specifikace jednotlivých částí SUS se odkazuje na některý z předchozích standardů.

Uživatelské a softwarové rozhraní pro operační systémy je specifikováno v těchto hlavních částech:

Seznam definic a konvencí používaných ve specifikacích a seznam hlavičkových souborů jazyka C Seznam utilit (awk, echo, ed a jiné) a popis shellu (Bourne shell) Seznam dostupných systémových volání jazyka C Vysvětlení standardu Rozhraní curses (volitelně)

Existují obchodní označení UNIX 95, UNIX 98 a UNIX 03 pro systémy splňující SUS verze 1, verze 2, respektive verze 3.

3.3 Linux Standard Base Linux Standard Base (LSB) [9] je společným projektem několika linuxových distribucí. Projekt organizačně podléhá Linux Foundation. Úkolem tohoto projektu je standardizovat interní struktury operačních systémů založených na Linuxu. Základy LSB jsou vystavěny na standardech POSIX a několika dalších otevřených standardech. Tyto standardy jsou v LSB v některých ohledech rozšířeny.

V LSB kompatibilním operačním systému musí být obsaženy konkrétní standardní knihovny, konkrétní nástroje a příkazy, konkrétní významy runlevelů, přesně specifikované vlastnosti tiskového subsystému, konkrétní rozšíření X Windows systému a standardní umístění souborů v rámci souborového systému.

4 Vybrané operační systémy

4.1 Linux Linux je UNIX-like operační systém postavený na linuxovém kernelu. Userspace tohoto systému je převzat převážně z GNU projektu. Je až na detaily POSIX kompatibilní.

4.2 Android Android je rozsáhlá platforma převážně tvořená open source, jež je zejména určena pro mobilní zařízení (chytré telefony, PDA, navigace a tablety).

Architekturu operačního systému Android lze rozdělit do několika samostatných vrstev (linuxové jadro, knihovny psané v C/C++, Android Runtime, Application Framework, uživatelské programy).

Nejnižší vrstvou je jádro operačního systému, které tvoří abstraktní vrstvu mezi použitým hardwarem a zbylým softwarem ve vyšších vrstvách. Jádro Androidu je postaveno na linuxovém jádře verze 2.6, novější verze budou používat verzi jádra 3.2.

Další vrstvou jsou knihovny psané v jazycích C/C++ a využívají různé komponenty systému. Tyto funkce jsou vývojářům poskytnuty prostřednictvím Android Application Framework. Zde jsou uvedeny některé z nich:

libc: založena na BSD libc OpenSSL SQLite FreeType OpenGL LibWebCore: odvozena od webkitu

Android Runtime vrstva je implementována virtuálním strojem DVM (Dalvik Virtual Machine) vycházejícím z JVM (Java Virtual Machine). DVM byl speciálně vyvinut pro platformu Android, je registrově orientovaný, využívá základních služeb linuxového jádra, například správu paměti, práci s vlákny a další. Každá spuštěná aplikace pod Androidem běží v samostatném procesu s vlastním

23 virtuálním strojem. DVM je založen na registrové architektuře na rozdíl od JVM, jež je založena na zásobníkové architektuře. Licenční politika DVM je odlišná od licenční politiky JVM. DVM je distribuován pod licencí „Apache License 2.0“. Runtime DVM byte kód je generován nástrojem dx z byte kódu JVM.

Pro psaní aplikací se používá vrstva Application Framework, která aplikacím zprostředkovává přístup k mnoha službám. Tyto služby implementují prvky uživatelského rozhraní, stavový řádek, podporu pro aplikace běžící na pozadí, sdílení dat mezi různými aplikacemi, podporu pro specifický hardware příslušného zařízení a mnoho dalších služeb a funkcí. Můžeme je rozdělit do následujících kategorií:

Sada prvků View: prvky UI (seznamy, textová pole, tlačítka, checkboxy a jiné) Content providers: přístup k obsahu od jiných aplikací Resource manager: přístup k řetězcům, grafice, souborům Notification manager: zobrazení upozornění ve stavovém řádku Aktivity manager: řídí životní cyklus aplikace

Nejvyšší vrstvou systému tvoří aplikace určené běžné uživatele. Tyto aplikace mohou implementovat některé z následujících komponent:

Aktivity: UI obrazovky Service: služby běžící na pozadí Content providers: zprostředkování přístupu k datům aplikace Broadcast reciever: zpracování oznámení (stav baterie, příchozí SMS a jiné)

Pro vývoj aplikací je volně dostupný Android Software Development Kit (SDK). Jeho součástí jsou:

SDK Tools: nástroj pro ladění, testování aplikace, správu Android Virtual Devices (AVD), Android emulátor a další nástroje SDK Platform tool: obsahuje nástroje pro vývoj v závislosti na verzi platformy Android SDK platforms

4.3 Mac OS X Mac OS X je UNIX-like operační systém od firmy Apple. Jádro systému je založeno na Mach kernelu. Tento systém je s POSIX kompatibilní. Od verze Snow Leopard je také SUS kompatibilní. Pro Mac OS X existuje Fuse4X [17], knihovna pro implementaci souborového systému v userspace. Fuse4X vychází z projektu MacFUSE [16], který není v současné době udržován. Pro Mac OS X je možné doinstalovat programy za pomoci nástroje Mac Ports.

4.4 Windows Windows je operační systém od firmy Microsoft určený pro osobní počítače i pro servery. Windows lze provozovat na architekturách x86 a x86_64. Existují též Windows CE pro embedded zařízení (ARM, MIPS). Tento operační systém se zásadně liší od Windows pro osobní počítače. Tím se tato práce nezabývá.

Aplikace, které jsou napsány pro Windows, používají pro přístup k systémovým službám Win32 API nebo Win64 API. Tato práce se Win64 API nezabývá.

Windows API Jedná se o API, které vyvinula firma Microsoft pro operační systém Microsoft Windows. Všechny programy v rámci Windows komunikují přes toto API s kernelem. Toto API obsahuje kromě základních funkcí i funkce pro vytváření uživatelského rozhraní. Funkčnost Windows API lze rozdělit do několika základních kategorií:

Základní služby poskytující přístup k souborovému systému, přístup k perifériím, správu procesů a vláken, přístup k registrům Windows a pomáhající při ošetřování chyb. (Implementace se nachází v souborech kernel32.dll a advapi32.dll.) Pokročilé služby (správa služeb, práce s registrem Windows, vypnutí nebo restart systému či správa uživatelských účtů) jsou implementovány v advapi32.dll. Graphics Device Interface (GDI) uživatelské rozhraní knihovna běžných dialogových oken Windows Shell

podpora síťových služeb (WinSock)

Windows a POSIX K provozování některých unixových aplikací pod Windows existuje několik řešení pro emulací POSIXového API ve Windows.

Microsoft POSIX subsystem Microsoft POSIX subsystem je jeden ze subsystémů operačních systémů založených na Windows NT. Implementuje pouze první verzi standardu POSIX, tedy POSIX 1. Microsoft POSIX subsystém byl do Windows přidán, aby Windows vyhovoval standardu FIPS 151-2. Windows NT 3.51 a Windows NT 4.0 byly certifikovány tímto standardem.

Windows Services for UNIX Protože první verze standardu POSIX neobsahuje podporu pro vlákna, RPC a sokety, vznikla implementace novějšího POSIXu: Windows Services for UNIX (SFU), použitelného od verze Windows NT 4.0. Od verze Windows XP není Microsoft POSIX subsystem součástí distribuce operačního systému, byl nahrazen volitelným subsystémem Interix.

Interix Interix je POSIX kompatibilní subsystém pro Windows NT od verze 4.0. Vznikl jako součást Windows Services for UNIX. Od Windows Server 2003/R2 je součásti SUA (Subsystem for UNIX-based Applications). Interix obsahuje tyto open source nástroje, programy a knihovny.

Základní unixové nástroje: vi, ksh, csh, ls, cat, awk, grep, kill, etc. Překladač GCC 3.3 s knihovnami a hlavičkovými soubory GNU Debugger Wrapper pro překladač Microsoft Visual Studio Podpora posixových vláken, sdílených knihoven včetně dynamického zavádění, signálů, soketů a IPC Klient pro X11 Podpora unixových práv Manuálové stránky

Interix existuje verzích pro 32-bit a 64-bit systémy. Podpora dlouhých souborů je implementována pouze v 64-bitové verzi.

Vývojové prostředí obsahuje překladače pro jazyky C, C++ a Fortran. Některé programy třetích stran jsou dostupné z repositáře Debian Interix Port. Ve Windows 8 byl Interix prohlášen Microsoftem za neperspektivní (deprecated) technologii.

UWIN UWIN [6] je projekt vytvořený Davidem Kornem (autor ksh). UWIN umožňuje přeložit a spustit pod Microsoft Windows programy určené pro operační systém UNIX, splňuje standard X/Open.

UWIN se skládá z knihoven, které emulují unixové API, hlavičkových souborů a vývojových nástrojů (as, cc, yacc, lex, make, ksh, ls, sed, cp, stty). Emulační knihovna unixového API (POSIX.DLL) běží pod Win32 API, proto programy používající UWIN mohou používat volání jak z Win32 tak z unixového API.

Pro překlad unixových aplikací lze použít kromě v UWINu nativního GCC také překladače C z Microsoft Visual Studia, případně i jiné překladače.

UWIN lze provozovat pod Windows NT ve verzích od 4.0 do verze 7. UWIN vyžaduje pro úplnou funkcionalitu souborový systém NTFS, lze jej s jistým omezením provozovat se souborový systém FAT. Poslední verze UWIN vydaná pro Windows Vista a Windows 7 je 5.0b.

Cygwin Cygwin [5] je kolekce nástrojů, které vytvářejí Linuxu podobné prostředí v systému Microsoft Windows. Základem Cygwinu je dynamická knihovna (cygwin1.dll) implementující základní POSIXové API pomocí systémových volání Windows. Užitím této knihovny lze provozovat některé UNIXové aplikace ve Windows. Projekt Cygwin obsahuje velké množství UNIXových programů, které jsou distribuovány binárními balíčky. Mimo jiné se jedná o kompilátor, jímž lze překládat další projekty ze zdrojových textů.

MinGW MinGW [7] (Minimalist GNU for Windows) je minimalistické vývojové prostředí, kterým lze vytvořit nativní aplikaci pro operační systém Microsoft Windows. Skládá se z překladače GCC a GNU binutils. Toto vývojové prostředí využívá přímo nativní knihovny a na rozdíl od výše zmíněného Cygwinu neimplementuje kompletní POSIX API.

4.5 Rozdíly mezi Windows a Linuxem Operační systémy Windows a Linux jsou od sebe velmi odlišné. Z pohledu programátora aplikací se Windows a Linux odlišují svými API. Pro odstranění vzájemné nekompatibility těchto API existuje mezivrstva, která emuluje API jednoho operačního systému na druhém.

Pro spuštění Windows aplikace pod Linuxem existuje projekt Wine [4]. Tento projekt emuluje Win32 vrstvu nad linuxovým API. Pro provozování aplikací určených pro Linux existuje mezivrstva Cygwin, která emuluje POSIX vrstvu nad Windows API.

Existence výše uvedených projektů dává možnost nahradit POSIXová volání za volání z Windows API při zachování částečné funkcionality portovaného programu.

Souborové API POSIX versus Win32 API pro práci se soubory v POSIXu a ve Win32 jsou rozdílná. Liší se v oddělovačích adresářů v cestě k souboru (viz kapitola „Cesta k souboru“). Z pohledu API existují tyto rozdíly:

typ deskriptorů otevřených souborů: o Win32 používá opakní handle o POSIX číselný identifikátor různá názvy sobě odpovídajících funkcí, odpovídající funkce nemusí existovat rozdílný počet typ argumentů sobě odpovídajících funkcí různá rozšíření funkcionality u sobě odpovídajících funkcí

Příkladem rozšířené funkcionality je režim TRUNCATE_EXISTING funkce CreateFile z Win32 API, který zkrátí délku existujícího souboru na nulovou délku při jeho otevření, pokud soubor neexistuje, vrátí chybu ERROR_FILE_NOT_FOUND. Funkce open (POSIXový protějšek CreateFile) tento režim nepodporuje.

Pro podrobnější přehled o vztahu mezi Win32 a POSIX API lze nahlédnout do zdrojových kódů Wine a Cygwinu, ve kterých je řešena problematika překladu mezi Win32 a POSIX API.

V následující tabulce je uveden seznam funkcí pro práci se soubory z POSIXu s odpovídajícími protějšky z Win32, pokud existují.

Tabulka 1 Porovnání Win32 API a POSIX API

Win32 API POSIX API CreateFile open, creat CloseFile close CopyFile - CreateDirectory mkdir DeleteDirectory rmdir DeleteFile unlink FindClose closedir FindFiles readdir FindFirstFile opendir, readdir FindNextFile readdir FlushFileBuffers fsync GetDriveType - GetFileAttributes stat, lstat GetFileInformation stat, lstat GetFileSecurity (ACL přístupová práva) stat, lstat (UGO přístupová práva) GetFileSize stat, lstat GetVolumeInformation fstatfs, statfs LockFile flock, fcntl (POSIX specifikuje pouze advisory lock) MoveFile Rename MoveFileExt Rename

Win32 API POSIX API OpenDirectory Opendir OpenFile Open ReadFile read SetEndOfFile Truncate SetFileAttributes chmod SetFilePointer Lseek SetFileSecurity Chmod SetFileShortName - SetFileTime Utime SetFileValidData Truncate SetVolumeLabel - UnlockFile flock, fcntl WriteFile write access chroot dup dup2 link readlink symlink

5 Popis zlomekFS

5.1 Historie zlomekFS Zlomek FS je distribuovaný souborový systém, který je realizován userspace aplikací napsanou v jazyce C. Pro jeho implementaci je použit linuxový framework FUSE (Filesystem in userspace).

Implementace zlomekFS vznikla v rámci diplomové práce Josefa Zlomka „Shared File System for a Cluster“ [29]. Implementace tohoto souborového systému byla realizována jako userspace aplikace. Pro propojení této aplikace s linuxovým VFS byl vytvořen speciální kernelový modul. Komunikační protokol mezi tímto kernelovým modulem a userspace aplikací zlomekFS je stejný jako komunikační protokol mezi jednotlivými uzly, na kterých je zlomekFS provozován. Formát tohoto protokolu je blízký XDR ze Sun RPC. Během vývoje linuxového kernelu dochází velmi často ke změnám jeho interního API. To může způsobovat nekompatibilitu tohoto modulu, který není součástí standardního linuxového kernelu, s novější verzí kernelu, a to i v podobě zdrojových kódů. Nekompatibilitu modulu s novým API kernelu je v tomto případě nutno řešit portací tohoto modulu na novější verzi kernelu.

Je možné se pokusit začlenit konkrétní modul do mainstreamu kernelu. Tento úkon není nejjednodušší, je potřeba dodat patch v příslušném formátu, dodržet kódovací standardy linuxového kernelu. Nejtěžší je přesvědčit správce zdrojových kódů, aby příslušný modul byl začleněn do stromu zdrojových kódů linuxového kernelu. Poslední krok je ve většině případů velmi těžko realizovatelný, proto je lepší zvolit pro řešení problému standardní moduly kernelu. Pro implementaci souborového systému v userspace je nejlepší použít FUSE, čímž odpadá práce spojená s portací kernelového modulu na novější verze kernelu.

Na první výše uvedenou diplomovou práci navazuje diplomová práce Miroslava Trmače „zlomekFS Over FUSE“ [32], která nahradila původní kernelový ovladač standardním FUSE rozhraním. V době vzniku této práce neimplementovalo FUSE všechnu podporu pro nasazení zlomekFS a bylo potřeba FUSE rozšířit o následující funkcionalitu: možnost zneplatnění inode a dentry cache v kernelu.

Tato práce také umožnila nasadit souborový systém zlomekFS na operační systém FreeBSD. Toto byl první pokus o portaci tohoto projektu na jiný operační systém. Vzhledem k tomu, že se nepodařilo patche výše uvedeného rozšíření FUSE aplikovat do mainstreamu libfuse, zůstala možnost nasadit zlomekFS na novější verzi linuxového kernelu pořád omezena.

Práce Rastislava Wartiaka „History and Backup Support for zlomekFS“ [32] doplnila do zlomekFS podporu pro verzování souborů, kdy si uživatel může prohlédnout starší verze souborů. Během této práce došlo k portaci zlomekFS na novější verzi FUSE, kde je již integrována podpora pro zneplatnění inode a dentry cache v kernelu.

Za zmínku stojí diplomová práce Jiřího Zouhara „Regression Testing For zlomekFS“ [31] doplňující nástroje pro regresní testování zlomekFS a také projekt v rámci kurzu Operační systémy, jenž doplňuje weakly connection režim umožňující omezit komunikaci mezi jednotlivými uzly v závislosti na rychlosti linky.

5.2 Platforma pro provozování zlomekFS Souborový systém vyžaduje pro svou funkčnost standardní knihovnu C, implementaci POSIXových vláken a POSIXové API pro práci se soubory, POSIXovou implementaci soketů, knihovnu pro podporu D-Bus a knihovnu libfuse. Pro svůj běh vyžaduje pro ukládání dat souborový systém, který má unikátní inody pro adresáře i soubory a implementuje unixová vlastnická a přístupová práva k souborům a adresářům.

Z POSIXové implementace vláken program používá kromě API pro práci s vlákny některá synchronizační primitiva, konkrétně mutex a conditional variable.

5.3 Popis jednotlivých komponent Zlomek FS je vícevláknová aplikace, jež se skládá z několika komponent: serveru pro podřízené uzly, klienta pro update dat z nadřízených uzlů, části komunikující s uživatelem přes knihovnu FUSE a části, kterou lze měnit některá

32 nastavení za běhu programu přes sběrnici D-Bus. Touto částí lze například modifikovat logovací úroveň programu.

Jednotlivým komponentám obslužného programu odpovídají vlákna, která je realizují:

main: hlavní vlákno programu update thread: vlákna, která se starají o aktualizaci dat souborového systému fuse thread: vlákna, která obsluhují požadavky souborového systému přes knihovnu FUSE configuration thread: vlákno, které se stará o aktualizaci sdílené konfigurace dbus control thread: vlákno, které se stará o změnu logovací úrovně programu

Obrázek 1 Vlákna ve zlomekFS

6 Portace na Windows Operační systém Windows byl zvolen jako cílová platforma pro zlomekFS. Windows. Důvodem pro tuto volbu byla výrazná odlišnost tohoto operačního systému od Linuxu.

6.1 Stav zlomekFS před portací Před započetím prací byl tento projekt v následujícím stavu:

Pro konfiguraci a překlad tohoto projektu byl použit balík Autotools. Jeho použití výrazně přispělo k přenositelnosti překladového systému na jiné unixové systémy. Hlubší průzkum nasazení tohoto překladového systému ukázal, že toto nasazení nebylo provedeno důsledně. Chyběly některé testy dostupnosti použitých knihoven a jejich verzí v cílovém operačním systému nebo nebylo možné specifikovat, zda výsledný překlad bude obsahovat ladicí kód, či nikoliv. V tomto překladovém systému nešlo ani zapnout nebo vypnout podporu verzování, ačkoliv to samotný kód umožňoval. Velmi nedeterministické chování při překladu způsobila existence souboru „config.h“ ve zdrojových kódech. Stejně pojmenovaný soubor generuje příkaz autoconf, tento soubor obsahuje makra nutná pro podmíněný překlad kódu. Nebylo možné přeložit zlomekFS odděleně od jeho zdrojových kódů.

Způsob runtime nastavení zlomekFS nebyl úplně konzistentní, a navíc částečně špatně dokumentovaný. Některé části se konfigurovaly přes přepínače programu, jiné přes konfigurační soubory. Formát těchto konfiguračních souborů byl nestrukturovaný. Samotná implementace načtení konfiguračních souborů byla špatně rozšířitelná o nové položky. Chyby v konfiguračních souborech nebyly vůbec reportovány uživateli.

ZlomekFS nebylo možné spustit bez práv administrátora. Pokus o jeho spuštění bez těchto práv způsobil jeho pád. V logovací knihovně nebyla totiž ošetřena chyba při pokusu o zápis do souboru.

Mezi další nedostatky patřil nefunkční umount (fusermount -u /mount/point). Obslužný program se neukončil, přestože se souborový systém odpojil.

Projekt pro implementaci souborového systému používal FUSE. Komunikační protokol mezi jednotlivými nody byl specifický pro Zlomek FS a serializace přenášených dat byla velmi podobná XDR protokolu SUN RPC. Tato implementace měla problém v případě rozšíření nějaké struktury přenášené tímto protokolem o nové položky. Byl problém se serializací a deserializací, kde bylo potřeba doplnit další algoritmy pro serializaci a deserializaci těchto položek. Tento problém se projevil při pokusu o spuštění Zlomek FS pod PPC Linuxem, kde byla opomenuta serializace části jedné struktury pro bigendian.

Dalším komunikačním rozhraním zlomekFS byl D-Bus, který měl zajistit lepší podporu pro ladění. Lze přes něj měnit logovací úroveň zlomekFS daemona. V budoucnu by mělo být možné přes něj změnit stav spojení mezi jednotlivými uzly (connected, weakly connected, disconnected). Ačkoliv není tato komponenta nutná pro funkci zlomekFS, nebylo jej možné bez této komponenty přeložit.

Dokumentace k projektu nebyla úplná. Souborový systém byl popsán v několika již zmíněných diplomových pracích. Pro pochopení funkcionality kompletního programu bylo potřeba tyto práce nastudovat, případně prostudovat zdrojový kód. Kvalita zdrojového kódu je v některých částech přijatelná a dostatečně zdokumentovaná, ale existují také části kódu, které jsou zdokumentovány nedostatečně a často bývají velmi nepřehledné. Za zmínku stojí i zbytečné části legacy kódu, které se nikde v aplikaci nepoužívají a zhoršují orientaci v kódu programu.

Všechny zdrojové kódy byly uloženy v jednom adresáři. Dle mého názoru tento flat model žádným způsobem neusnadňuje orientaci ve zdrojových kódech. Způsobuje, že délka souboru obsahujícího konkrétní implementaci příslušné funkcionality se odvíjí od její složitosti. Jedinou výjimkou z plochého modelu jsou nástroje pro Regression Testing [31] od Jiřího Zouhara umístěné v samostatném adresáři.

Dalším aspektem zhoršujícím orientaci v programu je více dialektů coding style v rámci projektu. Ve výše zmíněné práci Jiřího Zouhara lze najít některé zmínky o coding standards, které byly sepsány po vytvoření převážné části zlomekFS.

Ze zdrojových kódů vyplývá jejich neportabilita na FreeBSD, která byla kdysi deklarována. Tato portabilita nejspíše nebyla udržována. Důkazem této nekompatibility je použití #include .

Ze zdrojového kódu je také patrné, že nebyly korektně ošetřeny stavy po přerušení signálem. Návrat ze systémového volání s hodnotou errno = EINTR byl považován za chybový stav. Pokud aplikace používá vlákna, nemůže systémové volání v operačním systému Linux skončit s touto návratovou hodnotou. V případě jednovláknové aplikace může být návratové hodnota systémové volání errno = EINTR.

Systém zamykání prostředků byl velmi složitý. Jestliže některá funkce vyžadovala, aby byla zavolaná se zamčeným mutexem a přitom patřila do veřejného API, pak při každém volání této funkce musel být dodržen povinný systém zamykání, tj. musel být zamknut patřičný mutex před voláním této fuknce. Funkce často kontrolovaly stav zamykání pomocí assertů. Tento stav byl zřejmě způsoben doplněním těchto zámků do již existující aplikace.

Obecně se dá říct, že zlomekFS obsahoval mnoho globálních proměnných, které reprezentují jeho stav. Tyto proměnné jsou dostupné ze všech částí kódu a některé z nich nejsou ani nijak strukturovány. Například existuje globální proměnná pro název lokálního uzlu a proměnná obsahující handle lokálního uzlu. Tento stav můžeme připisovat postupnému iterativnímu vývoji programu bez cíleného refactoringu části kódu.

Některé z výše zmíněných problémů bude potřeba vyřešit před započetím portace na jiný operační systém.

6.2 Úpravy provedené před portací zlomekFS Před portací zlomekFS na Windows bylo nutné vyřešit několik problémů. Jako první byl řešen překladový systém. Byl nahrazen nástroj autotools nástrojem CMake a to z důvodu zpřehlednění samotného překladového systému, nativní podpory pro překlad a spouštění testů překládané aplikace a zrychlení samotného překladu. Během tohoto kroku došlo k rozdělení jednotlivých logických celků do stromové adresářové struktury. Byl rovněž vyřešen problém s konfigurací překladu (např: debug, release).

Ze zdrojových kódů byla odstraněna část legacy kódu, který již v programu nebyl používán. Jednalo se o zfsProxy a pozůstatky RPC pro komunikaci s původním kernelovým modulem.

Došlo k oddělení D-Bus interface ve zdrojovém kódu zlomekFS tak, aby zlomekFS mohl být přeložen bez jeho podpory. Došlo také k úpravě překladového systému.

Následovalo zprovoznění unit testů, které se budou hodit při následující portaci zlomekFS. V tomto kroku byl nahrazen proprietární nástroj pro unit testování google testem, a to z důvodu nekompatibility s novou verzí knihovny libelf. Jelikož je google test napsán za pomoci jazyka C++, bylo potřeba upravit příslušné hlavičkové soubory tak, aby byly kompatibilní s C++.

Ze syplogu byla odstraněna chyba, která způsobovala pád programu v případě, že program neměl dostatečná práva pro zápis logovacího souboru. Po opravě syplog loguje do konzole v případě, že nemá dostatečná práva pro zápis do logovacího souboru.

Bylo opraveno v kritických případech opraveno zpracování návratové hodnoty některých systémových volání (read, write), pokud volání skončí s chybou EINTR, je toto volání znovu zavoláno.

Byla nahrazena synchronizace hlavního vlákna a konfiguračního vlákna barrierou, původně se používaly uživatelem definované signály.

Další úpravy zlepšili integraci knihovny libfuse do zlomekFS, konkrétně se jednalo o ukončení zlomekFS daemona v případě, že byl odpojen od souborového systému.

Byla přepsána komponenta, která měla za úkol načtení konfigurace z konfiguračních souborů. Pro přístup ke konfiguračním souborům byla zvolena knihovna ligconfig. Porobnosti této úpravě jsou popsány v kapitole „Úpravy konfiguračních souborů“.

Následovala úprava parametrů, které jsou předány programu při jeho spuštění. Konkrétně se jednalo o přesunutí parametrů, které nastavovaly některé vlastnosti verzování, do lokální konfigurace.

K analýze komunikačního protokolu mezi uzly zlomekFS byl vytvořen dissector pro Wireshark. Další zkoumání komunikačního protokolu zlomekFS se nachází v kapitole „Komunikační protokol mezi uzly“.

V kódu byly nahrazeny v místech, kde to bylo možné, runtime inicializátory synchronizačních primitiv za statické, například u zfsd_mutexu. Touto úpravou byla výrazně zjednodušena inicializace a deinicializace jednotlivých komponent.

Pro zjednodušení testování zlomekFS by bylo přínosné, aby bylo možné spustit zároveň více instancí zlomekFS na jednom počítači. K tomu je potřeba umožnit změnit v konfiguraci číslo tcp portu, na kterém bude zlomekFS poslouchat. Tato úprava byla také realizována.

Úpravy konfiguračních souborů Jedním z výše popsaných problému zlomekFS byly konfigurační soubory. Konfiguraci zlomekFS lze rozdělit na konfiguraci lokálního uzlu a sdílenou konfiguraci. Sdílená konfigurace je uložená na konfiguračním volume zlomekFS a v případě její změny si ji jednotlivé uzly načtou automaticky.

Konfigurační soubory ve zlomekFS jsou textové a řádkově orientované. Dají se rozdělit do dvou typů dle struktury. První typ připomíná svou strukturou soubor z unixových systémů /etc/passwd. Každý řádek v tomto souboru odpovídá jednomu záznamu, jednotlivé položky v záznamu jsou od sebe odděleny znakem „:“. Druhý typ obsahuje na každém řádku záznam typu název proměnné a její hodnota, v tomto případě se jako oddělovač používá znak „=“.

Textové soubory jsou z hlediska portability mezi různými platformami problematické. Odlišné platformy implementují oddělovače jednotlivých řádků různě, například UNIX používá „\n“, Mac OS 9 „\r“ nebo Windows „\r\n“. Pokud bychom chtěli pracovat s textovými soubory z ostatních operačních systémů, museli bychom při zpracování textového souboru zohlednit výše uvedené

38 skutečnosti. Proto je výhodnější použít hotovou knihovnu pro načtení konfigurace.

Pro novou implementaci načtení konfigurace byla zvolena knihovna libconfig [14], kterou lze provozovat dle dokumentace pod Windows i pod Linuxem. Vstupní soubor umí načíst přímo z disku, nebo za pomoci typu FILE *. Během startu zlomekFS je potřeba načíst sdílenou konfiguraci, pro tento úkol se používá interní API zlomekFS pro práci se soubory. Před nasazením libconfig na zlomekFS se musí vyřešit problém s načtením sdílených konfiguračních souborů. Prvním řešením je zkopírovat soubor na lokální disk a načíst knihovnou libconfig lokální verzi, druhou variantou je implementovat vlastní FILE * handle užitím zlomekFS funkcí pro práci se soubory. Tuto variantu lze implementovat za pomoci funkce fopencookie, která patří do GNU rozšíření libc. Pro vyřešení problému byly implementovány obě varianty v knihovně zfsio. První varianta se vybere během překladu, pokud neexistuje na cílové platformě implementace funkce fopencookie, jinak se použije druhá varianta.

Z důvodu zjednodušení lokální konfigurace zlomekFS bylo sloučeno několik konfiguračních souborů do souboru jednoho.

Sloučením sdílených konfiguračních souborů by sice zjednodušilo konfiguraci zlomekFS, ale zároveň by v případě změny v části sdílené konfigurace muselo dojít k rekonfiguraci celého systému. Po zralé úvaze nedošlo ke sloučení sdílených konfiguračních souborů.

Popis nových konfiguračních souborů se nachází v adresáři se zdrojovými kódy v souboru README.

Komunikační protokol mezi uzly Komunikace mezi jednotlivými uzly souborového systému je realizovaná pro zlomekFS specifickým komunikačním protokolem. Tento protokol je postaven nad protokolem TCP, realizuje vzdálené volání procedur (RPC). V tomto protokolu jsou implementovány dva druhy volání (buď čekají na návratovou hodnotu, nebo nikoli). Formát serializovaných dat pro síťový přenos je podobný protokolu XDR (serializace dat pro sun RPC). Pro tento protokol neexistuje

39 nástroj pro generování interface podobný jako rpcgen v sun RPC. Interface je nutno vytvořit ručně.

Toto řešení je nenáročné na výpočetní výkon počítače, na kterém je zlomekFS provozován. Nevýhoda tohoto řešení se projeví v případě potřeby rozšíření protokolu. Tehdy je nutné modifikovat větší část kódu. Současně používaný protokol nemá prostředky pro detekci změny verze v komunikačním protokolu.

Pro usnadnění analýzy síťového provozu mezi uzly se hodí nástroj pro analýzu síťového protokolu. Tento nástroj může zjednodušit ladění některých komunikačních problémů mezi dvěma uzly. Pro realizaci tohoto nástroje byl použit projekt Wireshark, pro který lze implementovat vlastní modul (dissector) [13]. Modul byl implementován ručním přepisem částí kódu, které zlomekFS používá pro síťovou komunikaci. Nevýhodou tohoto řešení je, že v případě změny v komunikačním protokolu zlomekFS je potřeba ručně zanést tyto změny také do dissectoru.

Z výše uvedené skutečnosti je jasné, že by bylo vhodné vyřešit problém s negenerovaným komunikačním protokolem. První variantou je zachovat současný protokol a vytvořit k němu jazyk IDL (interface definition language), na základě kterého by šlo vygenerovat příslušný kód pro komunikaci mezi uzly. Druhou variantou je použití již hotového frameworku.

Realizovat první variantu by znamenalo navrhnout vlastní IDL jazyk, vytvořit pro něj překladač a generátor kódu. Realizace tohoto kroku je bezpochyby zajímavá, ale údržba takového projektu vyžaduje nemalé úsilí.

Pro volbu vhodného frameworku existují následující požadavky: rychlost, přenos základních datových typů a jednoduchých struktur, malá režie pro serializaci dat, detekce nedostupnosti uzlu, změření rychlosti propojení mezi uzly a zabezpečení dat proti modifikaci. Mezi volitelné požadavky patří zabezpečení komunikace mezi uzly proti odposlechu nebo podvržení, vzájemná autentifikace uzlů nebo řešení problémů s průchodností firewallu či NATů.

Protokoly založené na XML jsou v tomto případě nevhodné, a to z důvodu velikosti serializovaných dat a režie, která je nutná pro jejich serializaci

40 a deserializaci. Vhodnými frameworky pro komunikaci mezi uzly by mohly být Thirft, Protocol buffers a Zero ICE.

Protocol buffers [18] díky malé režii pro serializaci a deserializaci dat jsou vhodné pro nahrazení stávajícího komunikačního protokolu zlomekFS. Neoficiální podpora pro jazyk C [19] je výhodou pro jejich nasazení ve zlomekFS. Popsat komunikační protokol zlomekFS pomocí Protocol buffers není velký problém, jeho popis se nachází v souboru zfsd/lib/protocol/protobuf/zfs.proto zdrojových kódů zlomekFS. Protocol buffers neobsahuje použitelnou implementaci RPC pro zlomekFS. Nelze nastavit timeout pro RPC volání. Na straně serveru nelze paralelně zpracovat několik volání najednou. K plnohodnotnému použití Protocol buffers ve zlomekFS by znamenalo vytvořit vlastní implementaci transportní vrstvy, implementovat Stub a Proxy pro jednotlivá RPC volání. Protocol buffers by se používal pouze pro serializaci a deserializaci argumentů volání.

Implementovat kvalitní transportní vrstvu není jednoduché, proto je lepší použít ověřenou implementaci. Implementace transportní vrstvy ve Frameworku Zero ICE [20] je velmi propracovaná a jeho programátorská dokumentace je výrazně kvalitnější oproti Protocol buffers. Tento Framework nepodporuje jazyk C, ale podporuje jazyk C++. Za zmínku stojí velmi robustní implementace komunikačního spojení mezi dvěma uzly. Tento framework je nasazen v několika programech, což ukazuje na kvalitu jeho implementace.

Změny v implementaci zlomekFS nutné pro nasazení tohoto frameworku budou zřejmě velmi rozsáhlé. Z důvodu současně probíhající diplomové práce Matěje Klonfara „Weakly Connected Mode for ZlomekFS“ bylo v rámci této práce zastaveno další zkoumání týkající se komunikačního protokolu.

6.3 Nasazení zlomekFS na Windows První stanovenou podmínkou byla minimalizace zásadních změn do kódu programu, a to z důvodu rizika změny funkčnosti programu při větším zásahu do jeho kódu. Protože převážná část zlomekFS vyžaduje pro svou funkčnost POSIX, byl použit pro překlad zlomekFS pod Windows Cygwin. Bylo by možné použít UWIN, ale to by znamenalo řešit případné problémy v případě některých

GNU rozšíření v kódu zlomekFS. Z důvodu absence portu knihovny libfuse pro Windows, proto byla místo něj použita knihovna Dokan. V následujícím obrázku jsou znázorněny jednotlivé knihovny.

Obrázek 2 Dokan a zlomekFS

Díky použití těchto knihoven lze ve zlomekFS zachovat POSIXové konstrukty: vlákna, synchronizační primitiva, přístup k adresářům a souborům, práci se sítí. Jediná část, která využívá přímo Win32 API, je interface Dokanu do zlomekFS. Jedním z úkolů tohoto interface je zkonvertovat cestu k souboru ze syntaxe Windows do syntaxe UNIX (např. „Z:\data\myfile.txt“ na „/data/myfile.txt“). Vzhledem k tomu, že Win32 API pracuje s názvy souborů v UTF-16 kódování a Cygwin používá UTF-8 kódování, provádí Dokan interface konverzi názvu souborů mezi UTF-16 a UTF-8.

6.4 Úpravy provedené během portace zlomekFS na Windows Portace byla realizována postupně v několika krocích. Nejprve bylo nutné oddělit od zlomekFS stávající fuse interface. Takto upravený kód bylo možné zkusit přeložit pod Cygwinem.

Během překladu zlomekFS se ukázalo, že souborový systém pro svoji funkci potřebuje linuxový syscall SYS_getdents pro čtení obsahu adresáře. Tuto závislost na Linuxu bylo možné odstranit za pomoci readdir. Jedna ze zásadních věcí, která komplikovala vyřešení tohoto problému, byla skutečnost, že výše zmíněný syscall byl použit nejméně na čtyřech různých místech kódu programu. Dále se v Cygwinu chová jinak volání getaddrinfo oproti Linuxu a thread_id není jako v Linuxu celočíselný typ, ale jedná se o ukazatel.

Dále následovala implementace interface mezi zlomekFS a Dokanem. Bližší informace se nachází v kapitole „Windows FUSE“.

Protože linuxová knihovna libfuse obsahuje funkce pro zpracování argumentů programu a knihovna Dokan žádné takové funkce neimplementuje, bylo potřeba vytvořit vlastní funkci pro zpracování argumentů programu. Neboť programy pod Cygwinem mají stejné argumenty jako programy pod Linuxem, tato funkce zpracovává argumenty programu stejným způsobem, jako její protějšek z linuxové libfuse. Argumenty programu zlomekFS se pod Windows liší pouze v pojmenování přípojného bodu, Windows na rozdíl od Linuxu používají písmeno.

Hledání a odstraňování chyb v implementaci zlomekFS byla závěrečná část portace. Jedna těžko odhalitelná chyba byla v implementaci metasouborů. Změna metasouborů se prováděla na kopii. Poté, co byla kopie aktualizována, nahradila původní originál. Tento konkrétní problém spočíval v neuzavření originálního souboru v aplikaci před jeho přepsáním. V operačním systému Windows nelze přepsat soubor, který je otevřený. Nalezení této chyby bylo výrazně ztíženo tím, že v programu nejsou striktně kontrolovány návratové hodnoty systémových volání. V tomto případě se jednalo o systémové volání rename.

Během portace byly použity stávající unit testy, bylo doplněno několik unit testů týkajících se Dokan interface. Pro otestování základní funkcionality zlomekFS byl napsán jednoduchý nástroj, informace o testování zlomekFS a o tomto nástroji se nachází v kapitole „Testování zlomekFS nad Win32 API“.

Windows FUSE Knihovna Dokan zajišťuje propojení mezi userspace implementací souborového systému a kernelem operačního systému Windows. Knihovna Dokan komunikuje s implementací souborového systému pomocí tabulky ukazatelů na funkce. Ukazatel na tuto tabulku předává implementace souborového systému knihovně Dokan při její inicializaci.

Za pomoci Dokan API lze specifikovat, zda připojený souborový systém je case sensitive, zda je síťový, nebo naopak na vyjímatelném médiu.

Jak již bylo výše popsáno, Win API pro práci se soubory je odlišné od POSIX API. Dokan pro identifikaci otevřených souborů používá handle, zlomekFS používá odkaz na vnitřní strukturu nazývanou capability. V Dokan interface nejsou implementovány žádné cache na rozdíl od linuxového VFS. Veškeré operace, které provádí program s příslušným souborovým systémem, jsou přes Dokan provedeny v implementaci souborového systému.

Většinu funkcionality, kterou Dokan vyžaduje od souborového systému, lze implementovat i ve zlomekFS. Nelze implementovat zámky souborů, protože zlomekFS zámky souborů neimplementuje. Kromě toho nebyla do zlomekFS doimplementována Windows vlastnická a přístupová práva, neboť nejsou kompatibilní s modelem přístupových práv ve zlomekFS.

Knihovna Dokan používá vlastní správu vláken, proto je nutné pro funkcionalitu stávající části zlomekFS nastavit těmto vláknům specifické hodnoty, na které pak spoléhá kód zlomekFS. Tato nastavení vláken se provádí při zavolání příslušné funkce z rozhraní mezi zlomekFS a knihovny Dokan.

Testování zlomekFS nad Win32 API Pro testování souborových systémů pod unixovým operačním systémem existují nástroje fsx [27], Bonnie++ [25] nebo iozone [26]. Tyto nástroje je možné přeložit pod Cygwinem a použít ve Windows. Těmito nástroji nelze kompletně otestovat funkčnost souborového systému ve Windows, protože používají POSIXové API emulované Cygwin knihovnou, a tudíž nepracují přímo s Win32 API.

Pro ověření některých funkčností zlomekFS pod Windows byl vytvořen jednoduchý nástroj, který používá přímo Win32 API viz kapitola „Test rychlosti zlomekFS“.

6.5 Zhodnocení portu pro Windows Port zlomekFS pro Windows je dostatečně použitelný pro práci s dokumenty, k otevření souborů s hudbou nebo videem. Projekt je možné ve Windows pod Cygwinem bez problémů přeložit a spustit. Návod jak přeložit zlomekFS pod Windows se nachází v příloze „Zprovoznění zlomekFS pod Windows“. Lze nastavit písmeno jednotky, které bude použito pro připojení zlomekFS. V lokálním konfiguračním souboru je možné nastavit jméno oddílu zlomekFS. Je

44 možné nastavit počet vláken, který bude knihovna Dokan maximálně používat. Na tento souborový systém lze ukládat soubory s názvem se znaky z mezinárodní abecedy. Došlo také k zpřehlednění konfigurace zlomekFS.

Z uživatelského hlediska má tato implementace několik nedostatků. Není možné zjistit volné místo na zlomekFS oddílu. Další problém je rychlost zlomekFS, některé operace s tímto souborovým systémem trvají o trochu déle než na běžném souborovém systému, na základě tohoto pozorování bylo provedeno měření, jeho výsledky se nachází v kapitole „Test rychlosti zlomekFS“.

Během testování se ukázaly některé nedostatky v implementaci knihovny Dokan. Nelze z tohoto oddílu otevřít pdf v některých verzích Acrobat Readeru, není možné spustit aplikaci ze zlomekFS oddílu. Nelze smazat adresář přes Cygwin volání rmdir, to je způsobeno tím, že zavoláním unlink_nt s argumentem isdir = 1 dojde k vykonání kódu funkce dokan_delete_file namísto funkce dokan_delete_directory z Dokan interface. Výše uvedené nedostatky se projevují i u implementace souborového systému mirror. Problém se spuštěním programu z oddílu, který je připojený přes Dokan, byl již reportován na stránkách projektu. Na nově objevené nedostatky v implementaci Dokanu byl autor tohoto projektu upozorněn.

V portovaném programu jsou problémy se synchronizací dat mezi jednotlivými uzly, tyto nedostatky jsou i v současné stabilní verzi zlomekFS, ale byly řešeny v diplomové práci Jana Zálohy „Stability and Security of ZlomekFS“ [33]. Protože větev implementující tyto opravy nebyla v době psaní diplomové práce začleněna do stabilní větve zlomekFS, nebyly tyto změny otestovány ve větvi s portem zlomekFS na Windows.

Z programátorského pohledu došlo k zlepšení překladového systému, a to v jeho lepší konfigurovatelnosti, a také překlad za pomoci CMake je subjektivně rychlejší než autotools. Samotný kód zlomekFS byl pročištěn od legacy kódu a ze subjektivního hlediska byla organizace kódu zpřehledněna. Došlo ke zprovoznění unit testů a doplnění nových. Portací zlomekFS na Windows bylo ukázáno, že zlomekFS je možné provozovat operačním systému, který je výrazně odlišný od Linuxu.

Pro lepší integraci zlomekFS do Windows by bylo přínosné implementovat zlomekFS jako službu nebo vytvořit speciální logovací médium pro syplog.

Vzhledem k nahrazení nástroje pro unit testování gtestem [15] se dá předpokládat, že bude potřeba upravit testovací Framework, jenž vznikl během předchozí diplomové práce.

V době psaní diplomové práce byly všechny změny provedené v kódu aplikovány na aktuální stabilní verzi zlomekFS a byly také začleněny úpravy realizované v rámci diplomové práce Jana Zálohy „Stability and Security of ZlomekFS“ [33]. Výsledek tohoto spojení byl umístěn do nové větve.

6.6 Test rychlosti zlomekFS

Popis testu Rychlost zlomekFS byla měřena pomocí testu, který se skládá ze dvou částí: První část vytváří adresářovou strukturu, druhá část tuto strukturu zruší. Adresáře jsou uspořádané do stromové struktury, soubory se nachází pouze v poslední úrovni. Struktura se vytváří rekurzivně, nejprve se vytvoří adresář, pak jeho podadresář. Když je vytvořená dostatečná hloubka stromu, vytvoří se v nejhlubším adresáři příslušný počet souborů. Mazání souborů funguje obdobně. Jednotlivé operace se souborovým systémem jsou provedeny sekvenčně. Níže uvedené testy byly provedeny pro 4 úrovně adresářů, 5 adresářů v každé úrovni a 10 souborů v poslední úrovni. V rámci testu se měří doba trvání níže uvedených operací: open, close, write, mkdir, rmdir a unlink. Pro účel testů je zlomekFS v jednouzlové konfiguraci. Každý test byl opakován desetkrát.

Test pod Linuxem Testy byly provedeny na počítači s procesorem core i3 3GHz s operačním systému Ubuntu 64 bit. Test byl spuštěn na lokálním disku a na připojeném oddílu zlomekFS. Mediány z naměřených hodnot rychlosti pro každou operaci se nacházejí v následující tabulce:

Tabulka 2 Rychlosti disku a zlomekFS pod Linuxem operace disk (µS) zlomekFS (µS)

46 open 9,05 252,82 write 5,23 55,68 close 0,79 3,18 unlink 9,86 182,15 mkdir 24,36 280,21 rmdir 15,58 210,15

Grafické zobrazení výsledků, tedy kolikrát je pomalejší zlomekFS než disk, se nachází v následujícím grafu:

Obrázek 3 Porovnání rychlosti zlomekFS/disk pod Linuxem

30,00

25,00

20,00

15,00 zlomekFS

10,00

5,00

0,00 open write close unlink mkdir rmdir

Test pod Windows Testy byly provedeny na počítači s procesorem core i3 3GHz s operačním systémem Windoiws 7 Professional 64 bit. Test byl spuštěn na lokálním disku, na oddílu mirror a na připojeném oddílu zlomekFS. Byly vytvořeny dvě varianty testu, jedna používá Windows API, druhá používá POSIX API. Výsledky testu při použití Windows API se nachází v následující tabulce:

Tabulka 3 Rychlost disku, mirroru a zlomekFS pod Windows operace Disk (µS) Dokan (µS) zlomekFS (µS) open 92,58 261,05 645,64 write 21,80 40,27 646,99 close 233,91 236,78 645,32 unlink 76,47 343,11 549,55 mkdir 81,61 127,01 647,25 rmdir 80,66 216,20 496,79

Porovnání rychlost mirroru (Dokanu) a zlomekFS je v následujícím grafu. Zobrazené hodnoty jsou normovány rychlostí disku:

Obrázek 4 Porovnání rychlosti mirroru/disk a zlomekFS/disk pod Windows

35,00

30,00

25,00

20,00 Dokan 15,00 zlomekFS

10,00

5,00

0,00 open write close unlink mkdir rmdir

Výsledky testu při použití POSIX API emulovaného Cygwinem se nachází v následující tabulce:

Tabulka 4 Rychlost disku, mirroru a zlomekFS pod Cygwinem operace disk (µS) Dokan (µS) zlomekFS (µS) open 220,39 1769,10 8598,50 write 19,44 45,66 8594,80 close 241,96 271,74 8601,80 unlink 150,96 560,01 8353,32 mkdir 203,74 1684,18 8592,89 rmdir 89,39 200,31 8422,12

Porovnání rychlost mirroru (Dokanu) a zlomekFS je v následujícím grafu. Zobrazené hodnoty jsou normovány rychlostí disku:

Obrázek 5 Porovnání rychlosti mirroru/disk a zlomekFS/disk pod Cygwinem

500,00 450,00 400,00 350,00 300,00 250,00 Dokan 200,00 zlomekFS 150,00 100,00 50,00 0,00 open write close unlink mkdir rmdir

Porovnání výsledků Směrodatná odchylka je ve většině měření velká. Proto byl použit medián z naměřených hodnot místo aritmetického průměru, který je citlivější na výskyt odlehlých pozorování. Velikost směrodatné odchylky je způsobena tím, že některé operace trvají výrazně déle než v ostatních případech.

Rozložení naměřeného vzorku dat není podobné s normálním rozdělením. Nelze také vyloučit vliv neznámých okolností na měření. Nicméně pro přibližné porovnání rychlostí lze tyto výsledky použít.

Pro přehlednost jsou uvedeny hodnoty z Obr. 4, porovnání rychlosti zlomekFS a Dokan mirror versus nativní souborový systém pod Windows za použití Windows API je v následující tabulce (čísla v tabulce jsou násobky trvání zmíněné operace na nativním souborovém systému):

Tabulka 5 Porovnání rychlosti Dokanu a zlomekFS pod Windows operace Dokan zlomekFS open 2,82 6,97 write 1,85 29,68 close 1,01 2,76 unlink 4,49 7,19 mkdir 1,56 7,93 rmdir 2,68 6,16

Stejné porovnání za použití POSIX API, hodnoty z Obr 5, je v následující tabulce:

Tabulka 6 Porovnání rychlosti Dokanu a zlomekFS pod Cygwinem operace Dokan zlomekFS open 8,03 39,01 write 2,35 442,04 close 1,12 35,55 unlink 3,71 55,33 mkdir 8,27 42,18 rmdir 2,24 94,22

Porovnání rychlosti zlomekFS versus nativní souborový systém pod Linuxem (hodnoty z Obr. 3) je v následující tabulce:

Tabulka 7 Rychlost zlomekFS pod Linuxem operace zlomekFS open 27,94 write 10,64 close 4,05 unlink 18,47 mkdir 11,50 rmdir 13,49

Porovnání rychlosti zlomekFS pod Windows oproti rychlosti zlomekFS pod Linuxem je v následující tabulce (čísla v tabulce odpovídají násobku času potřebného na provedení příslušné operace pod Linuxem):

Tabulka 8 Porovnání rychlosti zlomekFS na Linuxu a na Windows operace zlomekFS open 2,55 write 11,62 close 202,71 unlink 3,02 mkdir 2,31 rmdir 2,36

Z tabulek je patrné, že největší režii má zlomekFS pod Windows. To může být způsobeno použitím Cygwinu. Při emulaci POSIXU Cygwinem je například operace open pětkrát pomalejší než odpovídající nativní operace z Windows API.

Ve zlomekFS se jedna operace souborového systému může promítnout do většího množství operací se souborovým systémem, na kterém jsou uložena data. Například operace zfs_open provádí kromě otevření souboru na cache oddílu také modifikaci souboru s metadaty.

Jedna operace nad zlomekFS může vyvolat několik operací nad diskem s lokální kopií souborů a adresářů (modifikace souborů s metadaty apod.). Pokud jsou tyto operace provedeny přes Cygwin, projeví se režije Cygwinu jako součet režií jednotlivých operací.

Operace close je výrazně pomalejší pod Windows než pod Linuxem. To může být způsobeno velmi propracovaným cachováním diskových operací v operačním systému Linux.

Naměřená data jsou uložena na přiloženém CD-ROMu.

7 Portace na jiné operační systémy

7.1 Android Podpora operačního systému Android pro vlastní souborového systému je nulová. Aplikace v operačním systému Android mají omezená práva přístupu k některým částem operačního systému, každá aplikace je v rámci systému spuštěna pod různým uživatelským účtem. Životní cyklus těchto aplikací je řízen operačním systémem, aplikace tedy může být téměř kdykoliv ukončena. Existuje několik možných variant, jak lze portovat zlomekFS na Android.

ZlomekFS je možné zprovoznit na Androidu jako „FTP klienta“ napsaného v jazyce Java coby nativní aplikaci pro Android. Kromě návrhu uživatelského rozhraní aplikace je potřeba znovu implementovat veškerou současnou funkcionalitu zlomekFS (komunikační protokol, aktualizace a cache souborů a adresářů, řešení konfliktů, verzování).

Aplikace pro Android může volat metody napsané v nativním kódu použitého procesoru za pomoci technologie JNI (Java Native Interface). Díky JNI by bylo možné použít části kódu ze současné implementace zlomekFS.

Pokud by se implementovalo přes JNI rozhraní knihovny libfuse, bylo by možné převzít velkou část kódu ze zlomekFS. Znamenalo by to vyřešit ve stávající implementaci několik problémů: konfigurace zlomekFS přes JNI, ukládání souborové cache na souborovém systému bez možnosti nastavit přístupová práva k souborům, adresářům, vyřešit spolehlivé spouštění a ukončování jednotlivých služeb zlomekFS, doplnit do syplogu logovací médium pro Android. Tato varianta je zajímavá po stránce jednotlivých technologií, ale po stránce implementační je velmi složitá, ladit chyby v nativním kódu muže být v jistých případech velmi náročné.

Na některých přístrojích s Androidem lze spustit aplikaci s právem uživatele root. Jedná se většinou o přístroje určené pro vývojáře. Lze pro ně přeložit běžné aplikace určené pro linuxové operační systémy a následně tyto aplikace na nich spustit, avšak platí pro ně některá omezení: použití embedded libc, nedostupnost mnoha standardních knihoven, překládání aplikace za pomoci

52 cross compilace. Ukázalo se, že knihovna libfuse nemůže být do Androidu přeložena ze zdrojových kódů, neboť vyžaduje při svém překladu funkci pthread_cancel v implementaci posixových vláken. Problém lze vyřešit modifikací zdrojových kódů knihovny libfuse tak, aby příslušné volání nepoužívala, nebo je možné přeložit vlastní verzi knihovnu GNU libc. Další problémem může být překlad fuse modulu do linuxového kernelu, zdrojové kódy linuxového jádra nutné pro překlad modulu mohou být nedostupné. Pro otestování funkčnosti zlomekFS na platformě operačního systému Android byla použita linuxová distribuce (ARM Debian), pod kterou bylo možné zlomekFS přeložit a spustit. Tímto krokem byla ověřena kompatibilita zlomekFS s procesorem založeným na architektuře ARM. Návod jak zprovoznit zlomekFS v chrootu pod Androidem se nachází v příloze „Zprovoznění zlomekFS pod Androidem ve chrootu“.

7.2 Mac OS X Tento operační systém patří mezi tři nejvíce používané operační systémy pro osobní počítače. Proto portace zlomekFS na tento operační systém může rozšířit uživatelskou základnu tohoto souborového systému.

Pro portaci byl použit zdrojový kód, který byl výsledkem portace na operační systém Windows. Ačkoliv Mac OS X je operační systém založený na Unixu, bylo potřeba pro zdárné dokončení portace vyřešit několik problémů.

Jeden z těchto problému byla absence volání pthread_yield, které způsobí přeplánování vláken. V Mac OS X není toto volání implementované, ale lze jej nahradit systémovým voláním shed_yield. Dále bylo potřeba vyřešit absenci volání fdopendir. Toto volání se muselo pro Mac OS X naimplementovat.

Tento port byl otestován pouze v konfiguraci s jedním uzlem.

8 Přenositelnost zlomekFS na odlišné architektury procesoru Pokud dochází k výměně binárních dat mezi různými architekturami, je potřeba zajistit, aby základní datové typy byly na obou architekturách interpretovány stejně a se stejnou přesností. Přenáší-li se strukturované datové typy, musí být v nich obsazené jednotlivé položky zarovnané tak, aby byly stejně deserializovány na různých architekturách.

Jedním z hlavních rozdílů mezi architekturou x86 a x64 z pohledu jazyka C je různá šířka základních datových typů. Datový typ int je široký 4 bajty na x86 a x64. Pokud bude do typu int uložena délka pole, jehož délka přesáhne 4 GB, pravděpodobně dojde ke ztrátě přesnosti. Obdobný problém vznikne při uložení ukazatele do typu int.

Architektury x86 a x64 mají různé volací konvence funkcí. Tuto odlišnost je potřeba reflektovat v případě, že jsou v kódu řešeny nízkoúrovňové problémy, jako je například výpis registrů procesoru.

Původní implementace zlomekFS byla určena pro 32bitovou architekturu x86 s operačním systémem Linux. Následná rozšíření zlomekFS byla testována na stejné 32bitové architektuře x86 s operačním systémem Linux. V kódu zlomekFS se nachází části, jež řeší problémy s odlišnou endianitou mikroprocesoru. Konkrétně se jedná o část kódu, která má za úkol serializovat a deserializovat přenášená data přes síť. Dále kód obsahuje části, které se překládají v závislosti na cílovém procesoru (x86 nebo x64). Tento kód má za úkol vypsat registry procesoru v případě pádu při běhu programu.

Během podrobného zkoumání kódu zlomekFS nebyla nalezena žádná záměna typu ukazatel za typ int. Datový typ string specifický pro zlomekFS obsahuje proměnnou typu uint32_t, která udává délku řetězce. Pokud by byl řetězec delší než 4GB, nestačil by rozsah proměnné pro uložení jeho délky. Protože nejdelší řetězec, který typ string reprezentuje, je cesta k souboru, nemůže nastat přetečení proměnné udávající délku řetězce.

Základní typy přenášené přes síť komunikačním protokolem zlomekFS jsou odvozeny od typů z hlavičkového souboru stdint.h, jejichž přesnost je stejná na

54 každé architektuře. Tím je zaručeno, že ztráta jejich přesnosti při přenosu je vyloučena. Vícebajtové celočíselné typy se při přenosu konvertují na little endian. Zarovnání položek struktur přenášených komunikačním protokolem zlomekFS je pevně stanoveno, a tedy nemůže nastat chyba v přenosu z důvodu různého zarovnání obsahu struktury.

Binární soubory, do nichž si zlomekFS ukládá metadata na lokálním cache oddílu, jsou mezi různými architekturami nepřenositelné. Jednotlivé celočíselné položky struktury s metadaty jsou sice uloženy v souboru jako little endian, ale celá struktura se ukládá do souboru tak, jak je uložena v paměti. Tento způsob ukládání struktur je nepřenositelný mezi různými architekturami, a to z důvodu odlišného zarovnání jednotlivých položek struktury v paměti. Protože záznam o metadatech souboru je spojen se samotným souborem přes inode tohoto souboru, není možné zkopírovat cache zlomekFS z jednoho diskového oddílu na druhý. Tedy řešit samotnou přenositelnost souborů ukládající metadata je v současné době zbytečné.

Funkčnost zlomekFS byla otestována testována na následujících platformách: Windows 7 32 bit, Windows 7 bit, Mac OS X 10.7 64 bit, Linux x86, Linux x64, Linux ppc 32 bit a Linux arm 32 bit. Základní interoperabilita byla z důvodu náročnosti testování ověřena mezi následujícími platformami: Linux x86 a Windows, Linux x86 a Linux PPC.

9 Návod pro psaní portabilního kódu souborového systému

9.1 Volba cílových platforem Cílové platformy, pro které je souborový systém prvotně určen, se nazývají primární. Existují také platformy, které nezvažujeme jako cílové během vývoje souborového systému. Dobrým pravidlem je psát program tak, aby bylo možné co možná s nejmenším úsilím doplnit podporu o tyto platformy.

9.2 Volba jazyka a překladového systému Pro implementaci souborového systému je potřeba zvolit jazyk, který je hodně rozšířený a dobře podporovaný (např. C, C++, Java, Python). Pokud existuje více překladačů konkrétního programovacího jazyka, je dobré zvolit ten nejvíce rozšířený. Překladač s podporou crosscompilace může výrazně usnadnit portaci programu na novou platformu. Pokud je potřeba použít generátor kódu (yacc, lex, rpcgen), je nutné zvážit způsob jeho použití. Zdrojové kódy lze buď generovat jednorázově v případě změny v jejich definicích, nebo je lze generovat při každém překladu programu. Generování kódu během každého překladu zjednodušuje překladový systém, ale je potřeba mít dostupný generátor na všech cílových platformách. Pro automatickou konfiguraci překladu v závislosti na cílové platformě je potřeba použít mezi platformami rozšířený překladový systém (autotools, cmake), nebo použít vlastní řešení.

9.3 Pravidla pro vytváření kódu Při psaní kódu je dobré dodržovat následující pravidla: nepoužívat zbytečně nestandardní rozšíření programovacího jazyka (GNU rozšíření) a pro komunikaci se systémem používat minimalistickou množinu dobře definovaného API (POSIX, libboost, glib2).

Je dobré nepoužívat datové typy, jejichž rozsah je závislý na příslušném procesoru nebo použitém překladači. Pro jazyk C jsou na platformě nezávislé typy int32_t, uint64_t a podobné, která jsou definované v hlavičkovém souboru stdint.h. Při použití těchto typů je vhodné pro jejich textový výpis použít formátovací řetězce typu PRIu32 z inttypes.h.

Vyhnout se používaní speciálních souborů v operačním systému jakou je například /dev/random. Pokud je nutné tyto soubory v konkrétním operačním systému nutné použit, pak je potřeba funkcionalitu, která tyto soubory používá, oddělit od zbylého kódu programu.

Pro systémy, ve kterých je dostupná knihovna libfuse, použijeme tuto knihovnu. V operačním systému Windows použijeme knihovnu Dokan. V některých operačních systémech lze použít proprietární řešení pro implementaci souborového systému v userspace (arla). Pokud pro operační systém existuje klient nějakého síťového souborového systému (NFSv2), u kterého je dostupná dokumentace komunikačního protokolu, může být implementace souborového systému v userspace realizována jako server pro tento síťový souborový systém. Server je pak možné provozovat na localhostu.

Budeme-li implementovat více typů interface pro souborové systémy, je dobré pro tyto implementace vytvořit samostatné minimalistické objekty s jednotným rozhraním směrem k aplikaci realizující souborový systém.

Pro programovací jazyk python existuje knihovna pro implementaci souborového systému Pyfilesystem. Tato knihovna funguje jak pod Linuxem (používá libfuse), tak pod Windows (používá Dokan).

Rozdělením programu do různých adresářů podle komponent výrazně zlepší jeho přehlednost a zjednoduší v něm orientaci. Oddělením na platformě závislých částí od na platformě nezávislých částí usnadní následný proces portace na novou platformu.

Vhodnou volbou coding style a jeho následným dodržováním lze výrazně zlepšit přehlednost ve zdrojovém kódu programu. Pokud na projektu spolupracuje více programátorů, je nutné dodržovat coding style. Coding style použitý ve zlomekFS je popsán v příloze „ZlomekFS C Coding style“.

9.4 Ladění a verifikace programu Po zapnutí u překladače vhodné množiny varování, která překladač může generovat, je vhodné po následném překladu tato varování překladače v kódu odstranit.

Pro překlad je dobré aktivovat všechna zásadní varování, která může překladač generovat. Při překladu je dobré se pokusit ze zdrojových kódů všechna varování odstranit. Nástroje pro statickou analýzu kódů (coverity [28]) mohou odhalit veliké množství chyb, proto je vhodné zvážit jejich nasazení.

Testovatelnost kódu může snížit počet chyb, které se projeví například při portaci programu na novou platformu. Testovat lze jednotlivé komponenty (unit testy), propojení komponent (integrační testy) nebo celý program (systémové testy). Testy jsou pro program stejně důležité jako jeho implementace.

Závěr Dle statistik jsou v dnešní době na osobních počítačích nejvíce zastoupeny Windows, a tedy lze předpokládat, že portace zlomekFS na Windows přinese rozšíření uživatelské komunity. V tomto případě může být zlomekFS nasazen jako síťový souborový systém v heterogenním síťovém prostředí.

V rámci diplomové práce se podařilo prozkoumat možnost implementace souborového systému v userspace za pomoci jiné knihovny, než je linuxová libfuse. Během práce vznikl dostatečně funkční port zlomekFS pro operační systém Windows. Na tomto souborovém systému lze vytvářet, mazat nebo modifikovat soubory, tedy lze na něm přehrát audio nebo video, prohlížet na něm obrázky. Konkrétně byl program testován pod následujícími operačními systémy: Windows XP a Windows 7. Byla ověřena funkcionalita pod 32 bit a 64 bit verzí Windows 7. Neměl by být problém nasadit zlomekFS i na Windows Vista nebo Windows 8. Tím se podařilo prokázat, že je možné tento souborový systém portovat na operační systém, který je výrazně odlišný od Linuxu.

K vytvoření portu zlomekFS pro Windows bylo nutné vyřešit několik problémů, jež nesouvisely přímo s portací. Byl přepsán překladový systém za použití nástroje CMake a došlo k rozšíření a zlepšení konfigurace tohoto překladového systému. Byl nahrazen proprietární nástroj na unit testování standardním google testem a zlomekFS byl rozšířen o některé nové testy. Došlo k odstranění kódu, jenž vznikl v rámci předchozích prací a nebyl již v současné době používán. Některé části kódu byly zpřehledněny, například došlo k přepisu spouštění jednotlivých komponent zlomekFS. Pro načtení konfigurace zlomekFS byla použita knihovna libconfig. Během integrace knihovny libconfig zlomekFS došlo k zjednodušení a k zpřehlednění v jeho konfiguračních souborech. Byly vyřešeny některé detaily v integraci knihovny libfuse. Všechny změny provedené v rámci této práce jsou připraveny k začlenění do aktuální verze zlomekFS.

V této práci byly sepsány rady, jak vytvořit a udržovat portabilní kód programu. Dále byla prozkoumána možnost portace zlomekFS na operační systém Android a na operační systém Mac OS X. Kromě toho byly porovnány operační systémy

Unix a Windows z hlediska jejich API pro přístup k souborům. Mimo to byla v práci analyzována možnost změny komunikačního protokolu zlomekFS.

Do budoucna by stálo za promyšlení, jakým směrem se má práce na tomto projektu ubírat. Bylo by dobré specifikovat, jakou funkcionalitu by mohl uživatel od zlomekFS očekávat a jak mu ji co nejlépe poskytnout. Testy prováděné komunitou uživatelů mohou být velmi přínosné pro odhalení chyb funkčnosti a pro zjištění zásadních výkonnostních nedostatků. Dalším úkolem zjednodušujícím běžnému uživateli konfiguraci programu zlomekFS by mohl být průvodce, jenž by vygeneroval celou konfiguraci nutnou pro spuštění programu.

Seznam použité literatury [1]. Windows API List. URL: [cit. 2012-6-5]. [2]. Dokan. URL [cit. 2011-1-12]. [3]. Libfuse. URL: [cit. 2011-6-22] [4]. Wine. URL: [cit. 2012-6-23] [5]. Cygwin. URL: [cit. 2012-6-23] [6]. Uwin Overview [cit. 2012-3-13] [7]. Mingw. URL: [cit. 2012-5-18] [8]. The UNIX system URL: [cit. 2012-6-23] [9]. Linux Standard Base (LSB) URL: [cit. 2012-4-29] [10]. CMake. URL: [cit. 2012-4-19] [11]. Autotools Tutorial URL: [cit. 2010-5-20] [12]. The GNU C Library. URL: [cit. 2003-6-23] [13]. Wireshark programmers reference. URL: [cit. 2012-6-22] [14]. Libconfig reference. URL: [cit. 2012-8-12] [15]. Googletest. URL: [cit. 2012-6-23] [16]. Macfuse URL: [cit. 2012-6-20] [17]. Fuse4x URL: [cit. 2012-6-18] [18]. Protocol Buffers URL: [cit. 2012-6-20] [19]. Protobuf-c URL: [cit. 2012-6-20] [20]. ZeroC URL: [cit. 2012-4-17] [21]. CFS URL: [cit. 2001-5-10] [22]. Arla URL: [cit. 2007-1-13] [23]. Comparison of file systems. URL: [cit. 2012-6-20] [24]. Indent style URL: [cit. 2012-6-20] [25]. Bonnie++ URL: [cit. 2012-2-4] [26]. IOzone Filesystem Benchmark URL: [cit. 2012-6-20] [27]. fsx URL: [cit. 2012-6-20]

[28]. Coverity URL: [cit. 2012-6-20] [29]. ZLOMEK, J. Shared File System for a Cluster. Praha, 2004. 53 s. Diplomová práce na Matematicko-fyzikální fakultě Univerzity Karlovy na katedře softwarového inženýrství. Vedoucí diplomové práce doc. Ing. Petr Tůma, Dr. [30]. TRMAČ, M. zlomekFS Over FUSE. Praha, 2007. 67 s. Diplomová práce na Matematicko-fyzikální fakultě Univerzity Karlovy na katedře softwarového inženýrství. Vedoucí diplomové práce doc. Ing. Petr Tůma, Dr. [31]. ZOUHAR, J. Regression Testing For zlomekFS. Praha, 2007. 74 s. Diplomová práce na Matematicko-fyzikální fakultě Univerzity Karlovy na katedře softwarového inženýrství. Vedoucí diplomové práce doc. Ing. Petr Tůma, Dr. [32]. WARTIAK, R. History and Backup Support for zlomekFS. Praha, 2010. 56 s. Diplomová práce na Matematicko-fyzikální fakultě Univerzity Karlovy na katedře softwarového inženýrství. Vedoucí diplomové práce Mgr. Vlastimil Babka. [33]. ZÁLOHA, J. Stability and Security of ZlomekFS. Praha, 2012. Diplomová práce na Matematicko-fyzikální fakultě Univerzity Karlovy na katedře distribuovaných a spolehlivých systémů. Vedoucí diplomové práce Mgr. Vlastimil Babka.

Seznam tabulek

Tabulka 1 Porovnání Win32 API a POSIX API ...... 29 Tabulka 2 Rychlosti disku a zlomekFS pod Linuxem ...... 46 Tabulka 3 Rychlost disku, mirroru a zlomekFS pod Windows ...... 47 Tabulka 4 Rychlost disku, mirroru a zlomekFS pod Cygwinem ...... 48 Tabulka 5 Porovnání rychlosti Dokanu a zlomekFS pod Windows ...... 49 Tabulka 6 Porovnání rychlosti Dokanu a zlomekFS pod Cygwinem ...... 50 Tabulka 7 Rychlost zlomekFS pod Linuxem ...... 50 Tabulka 8 Porovnání rychlosti zlomekFS na Linuxu a na Windows ...... 50 Tabulka 9 Názvy souborů a adresářů ...... 67 Tabulka 10 Metadata ...... 68 Tabulka 11 Vlastnosti souborových systémů ...... 68 Tabulka 12 Podpora v operačních systémech ...... 68

Seznam použitých ilustrací

Obrázek 1 Vlákna ve zlomekFS ...... 33 Obrázek 2 Dokan a zlomekFS...... 42 Obrázek 3 Porovnání rychlosti zlomekFS/disk pod Linuxem...... 47 Obrázek 4 Porovnání rychlosti mirroru/disk a zlomekFS/disk pod Windows .. 48 Obrázek 5 Porovnání rychlosti mirroru/disk a zlomekFS/disk pod Cygwinem 49

Seznam použitých zkratek ABI Application binary interface ACL Access control list ALU arithmetic logic unit API Application Programming Interface CFS Cryptographic Filesystem CPU Central Processing Unit FIPS Federal Information Processing Standard FTP File Transfer Protocol FUSE Filesystem in Userspace HW Hardware LSB least significant byte MSB most significant byte PDA Personal Digital Assistant PIC Personal Independent Code UI user interface USB Universal Serial Bus (sběrnice) VAX Virtual Address eXtension (HW počíčová platforma) VMS Virtual Memory System (operační systém) WWW World Wide Web x86 označení pro rodinu procesorů založené na procesoru Intel 80386 x64 označení pro rodinu 64-bit procesorů odvozené od procesoru Intel 80386

Přílohy

A. Obsah CD-ROMu Přiložený CD-ROM obsahuje následující soubory: bin přeložený zlomekFS pro vybrané platformy bin/android adresář root souborovým systémem arm Linuxu bin/android/debian-arm bin/android/debian-arm/disk.img bin/android/debian-arm/mnt bin/android/debian-arm/mount.sh bin/windows binárky pro platformu windiws bin/windows/cygwin binarky s Cygwinem bin/windows/cygwin/cygwin_zlomekfs_dev.zip připravená instalace Cygwinu pro překlad zlomekFS bin/windows/cygwin/setup.exe instalátor Cygwinu bin/windows/dokan bin/windows/dokan/DokanInstall_0.6.0.exe instalátor knihovny Dokan bin/windows/zlomekFS.zip přeložený zlomekFS pro platformu windows src adresář se zdrojovým kódem zlomekFS src/zlomekfs.tgz zdrojový kód zlomekFS tests adresář s výsledky testů tests/cygwin.xlsx výsledek test pod Cygwinem tests/linux.xlsx výsledek testu pod linuxem tests/summary.xlsx shrnutí výsledků testu tests/winapi.xlsx výsledek testu pod winapi thesis adresář s textem diplomové práce thesis/Snuparek-PortabilityInZlomekFS.pdf text diplomové práce

B. Porovnání vybraných souborových systémů V následujících tabulkách jsou porovnány vybrané souborové systémy na základě některých charakteristik (jména souborů a adresářů, metadat, vlastností, jejich implementacích v různých operačních systémech). Tento přehled vychází z Comparison of file systems [23].

Tabulka 9 Názvy souborů a adresářů

Souborový Délka názvu Povolené znaky v názvu Maximální délka Maximální Maximální systém souboru cesty délka velikost FS souboru Apple DOS 30 bajtů vše až na NULL 30 B, žádné není 113.75 kB DOS podadresáře, (105 definováno 3.1, 3.2 souborů na jednom 140 kB DOS 3.3 disku) HFS Plus 255 UTF-16 libovolný Unicode neomezeno 8 EB 8 EB znaků FAT12 8.3 (255 UTF-16 vše až na 0-31, 127 (DEL) a: " * / : 32 MB, nebo 32 MB, nebo znaků s LFN1) < > ? \ | + , . ; = [] (lowcase a-z se 256 MB 256 MB ukládá jako A-Z). Ve VFAT LFN libovolný Unicode až na NUL FAT16 8.3 (255 UTF-16 8.3 (255 UTF-16 Unicode znaků není definováno 2 GB (4 GB) 2 GB, nebo 4 GB znaků s LFN) s LFN) FAT32 8.3 (255 UTF-16 vše až na 0-31, 127 (DEL) a: " * / : není definováno 4 GB 2 TB, nebo znaků s LFN) < > ? \ | + , . ; = [] (lowcase a-z se 16 TB ukládá jako A-Z). Ve VFAT LFN libovolný Unicode až na NUL exFAT 255 znaků libovolný Unicode mimo NUL není definováno 127 PB 64 ZB, doporučených 512 TB NTFS 255 znaků libovolný Unicode mimo NUL a „\ 32,767 Unicode 16 EB 16 EB / : * ? " < > |“ znaků ext2 255 bajtů libovolný Unicode mimo NUL a / není definováno 2 TB 32 TB ext3 255 bajtů libovolný Unicode mimo NUL a / není definováno 2 TB 32 TB ext4 255 bajtů libovolný Unicode mimo NUL a / není definováno 16 TB 1 EB XFS 255 bajtů libovolný bajt mimo NUL není definováno 8 EB 8 EB ZFS 255 bajtů libovolný Unicode mimo NUL není definováno 16 EB 16 EB

1 LFN (support for long filenames) podpora dlouhých názvů souborů, adresářů

Tabulka 10 Metadata

Souborový Vlastník POSIX Čas Čas posledního Čas Čas ACL systém souboru práva vytvoření přístupu, čtení změny archivace HFS Plus Ano Ano Ano Ano Ano Ano Ano FAT32 Ne Ne Částečná Částečná Ano Ano Ne exFAT Ne Ne Částečná Částečná Ano Ano Ne NTFS Ano Ano Ano Ano Ano Ano Ano ext2 Ano Ano Ano Ano Ano Ne Ano ext3 Ano Ano Ano Ano Ano Ne Ano ext4 Ano Ano Ano Ano Ano Ne Ano XFS Ano Ano Ano Ano Ano Ne Ano ZFS Ano Ano Ano Ano Ano Ne Ano

Tabulka 11 Vlastnosti souborových systémů

Souborový Hard Symbolické Block Metadata-only Case- Case- systém linky linky journaling journaling sensitive preserving FAT12 Ne Ne Ne Ne Ne Částečná FAT16 Ne Ne Ne Ne Ne Částečná FAT32 Ne Ne Ne Ne Ne exFAT Ne Ne Ne Ne Ano NTFS Ano Ano Ne Ano Ano Ano HFS Plus Ano Ano Ne Ano Částečná Ano ext2 Ano Ano Ne Ne Ano Ano ext3 Ano Ano Ano Ano Ano Ano ext4 Ano Ano Ano Ano Ano Ano XFS Ano Ano Ano Ano Ano Ano ZFS Ano Ano Ano Ne Ano Ano

Tabulka 12 Podpora v operačních systémech

Souborový systém Windows Mac OS X Linux FAT12 Ano Ano Ano FAT16 Ano Ano Ano FAT32 Ano Ano Ano exFAT Ano Ano Ano NTFS Ano NTFS-3G NTFS-3G HFS Plus Ne Ano Částečná ext2 Ne Ne Ano ext3 Ne Ne Ano ext4 Ne Ne Ano XFS Ne Ne Ano ZFS Ne Ne Ne

C. Zprovoznění zlomekFS pod Windows Pro překlad zlomekFS pro Windows musíme nainstalovat Cygwin. zlomekFS bylo provozováno s verzí 1.7.11-1. Pro překlad potřebujeme kromě základního systému navíc tyto balíčky: make 3.82.90-1, cmake 2.8.7-1, gcc 4.3.4-4, g++ 4.5.3-3, python 2.6.7-1, openssl-devel 1.0.1-1, pkg-config 0.23b-10, unzip 6.0-10 a subversion 1.7.4-1.

Dále je potřeba přeložit ze zdrojových kódů knihovnu libconfig a gtest. Překlad knihovny libconfig:

$ wget http://www.hyperrealm.com/libconfig/libconfig-1.4.8.tar.gz $ tar xzf libconfig-1.4.8.tar.gz $ cd libconfig-1.4.8 $ ./configure $ make $ make install Překlad gtestu:

$ wget http://googletest.googlecode.com/files/gtest-1.6.0.zip $ unzip gtest-1.6.0.zip $ cd gtest-1.6.0 $ ./configure $ make & make install # manual installation $ cp *.a /usr/local/lib/ $ cp -a include/gtest /usr/local/include/ Poslední prerekvizitou je Dokan, který nainstalujeme instalátorem knihovny. Jelikož v tomto instalátoru chybí jeden hlavičkový soubor, musí se ještě stáhnout zdrojové kódy ze SVN.

$ cp /cygdrive/c/Program\ Files/Dokan/DokanLibrary/dokan.lib /usr/local/lib/ $ cp /cygdrive/c/Program\ Files/Dokan/DokanLibrary/dokan.h /usr/local/include/ $ cat > /usr/local/lib/pkgconfig/dokan.pc <

Name: Dokan Description: Library for Windows Userspace FS Version: 0.6.0 Libs: -L${libdir} –ldokan Cflags: -I${includedir} TEXT #checkout sources from SVN $ svn checkout http://dokan.googlecode.com/svn/trunk/ dokan-read-only $ cp dokan-read-only/dokan/fileinfo.h /usr/local/include/

Před překladem samotné aplikace je potřeba nastavit některé proměnné prostředí:

$ echo 'export LIBRARY_PATH=/usr/local/lib:${LIBRARY_PATH}' >> "${HOME}"/.bashrc $ echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH}' >> $ "${HOME}"/.bashrc $ . "${HOME}"/.bashrc Přípravu pro překlad a překlad provedeme následujícími příkazy:

$ svn checkout https://shiva.ms.mff.cuni.cz/svn/zlomekfs/branches/snuparek zlomekfs $ cd zlomekfs #build $ ./makeall.sh #prepare configuration $ cp -a conf/single/etc/zfsd /etc/ $ cp -a conf/single/var/zfs /var/ $ mkdir -p /var/zfs/data Spuštění zlomekFS provedeme následujícím příkazem:

$ ./build/zfsd/zfsd/zfsd.exe -o config=/etc/zfsd/zfsd.conf z Pro spuštění zlomekFS je možno použít binární verze zlomekFS, nachází se na přiloženém CD-ROMu .bin/windows/zlomekFS.zip. Před jeho spuštěním je potřeba nainstalovat knihovnu Dokan, instalace se nachází na přiloženém CD bin/windows/dokan/DokanInstall_0.6.0.exe. ZlomekFS se spouští souborem zlomekFS\zfsd_single.bat v jednouzlové konfiguraci. Pro spuštění zlomekFS v dvouuzlové konfiguraci na jednom počítači jsou soubory zlomekFS\zfsd_master.bat a zlomekFS\zfsd_slave.bat.

D. Zprovoznění zlomekFS pod Androidem ve chrootu Pro překlad a spuštění zlomekFS na Android telefonu musíme splnit několik prerekvizit:

Android zařízení s možností spustit aplikaci s právy uživatele root Přeloženou podporu fuse v kernelu přístroje s Androidem Dostatečně velikou paměťovou kartu Počítač s nainstalovaným Linuxem a Android SDK

Příprava root souborového systému na počítači s Linuxem:

$ cp –a -/mnt/cdrom/android/debian-arm /mnt/sdcard # odpojíme sdkartu a vrátíme ji do přístroje s Androidem # připojíme Android v debug režimu k počítači Zprovoznění chrootu na Android telefonu:

$ adb shell $ cd /sdcard/debian-arm # mount and chroot into debian rootfs $ ./mount.sh $ cd /root/src/zlomekfs $ ./makeall #build $ ./makeall.sh #prepare configuration $ cp -a conf/single/etc/zfsd /etc/ $ cp -a conf/single/var/zfs /var/ $ mkdir -p /var/zfs/data $ mkdir –p mnt Spuštění zlomekFS provedeme následujícím příkazem:

$ ./build/zfsd/zfsd/zfsd -o config=/etc/zfsd/zfsd.conf mnt # v adresáři mnt jsou vyexportovány zlomekFS oddíly $ find mnt # umount zlomekFS, stop zlomekFS daemon $umount mnt

E. Překlad Wireshark dissectoru pro analýzu zlomekFS komunikačního protokolu Implementace Wireshark dissectoru se nachází v adresáři dissector zdrojových kódů zlomekFS. Dissector byl testován s revizi r34978 Wiresharku.

Pro překlad je potřeba získat zdrojové kódy Wiresharku ze SVN:

$ svn checkout -r34978 http://anonsvn.wireshark.org/wireshark/trunk wireshark Zkopírovat plugin do zdrojových kódů Wiresharku:

$ svn checkout https://shiva.ms.mff.cuni.cz/svn/zlomekfs/branches/snuparek zlomekfs $ cp –a zlomekfs/dissector/wireshark/plugins/zfsd wireshark/plugins/ #patch build systém $ cd wireshark $ patch –p1 < ../zlomekfs/dissector/wireshark_build.diff Překlad a spuštění Wiresharku:

$./configure && Make $ export WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 $./wireshark

F. ZlomekFS C Coding style Coding style používaný pro úpravy provedené v rámci této práce vychází Allman stylu [24]. Zdrojový kód lze zkonvertovat do tohoto stylu nástrojem indent:

$ indent -bap -bli0 -i4 -l79 -ncs -npcs -npsl -fca -lc79 -fc1 -ts4 my.c Následující příklady jsou založeny na práci Jiřího Zouhara „Regression Testing For zlomekFS“ [31].

Identifikátory se píší malými písmeny, u víceslovných identifikátorů jsou jednotlivá od sebe odděleny podtržítkem.

uint32_t log_level; Názvy maker se píší velkými písmeny, u víceslovných maker jsou od sebe jednotlivá slova oddělena podtržítkem.

#define MY_MACRO_CONSTANT 5 Definice typů se píší malými písmeny a obsahují příponu _t.

typedef uint32_t fibheapkey_t; Každá ze složených závorek kolem bloku by měla být na novém řádku a závorky by měly být odsazeny na úrovni předchozího kódu.

syp_error set_log_level (logger target, log_level_t level) {

target->log_level = level; return NOERR;

} Závorky kolem argumentů funkce by měly být odděleny od názvu funkce jednou mezerou. Pokud je seznam argumentů funkce zapsán na více řádcích, uzavírací závorka argumentů by měla být na stejné řádce jako poslední argument.

syp_error send_uint32_by_function (uint32_t data, syp_error (*function) (int, uint32_t, const struct sockaddr *, socklen_t), const char * ip, uint16_t port);

Pro odsazení by se měl používat jeden tabulátor na úroveň.

syp_error dbus_disconnect(DBusConnection ** connection) { if (connection == NULL) return ERR_BAD_PARAMS; if (*connection == NULL) return ERR_NOT_INITIALIZED; dbus_bus_release_name (*connection, SYPLOG_DEFAULT_DBUS_SOURCE, NULL); dbus_connection_unref(*connection); *connection = NULL; return NOERR; } Operátory by měly být odděleny od argumentů jednou mezerou z jedné i z druhé strany.

file_position += bytes_written; Komentáře by měly být před kódem, který popisují. Text komentáře by měl být od znaku začátku a konce komentáře oddělen mezerou.

/*! Structure holding logger state and configuration. */ typedef struct logger_def { /// input - output medium definition struct struct medium_def printer; Jednotlivá slova ve víceslovném názvu souboru by se měla od sebe oddělovat spojovníkem.

control-protocol.h