%fithesis; ]> Diplomová práce Libor Vaněk false fi Jan Kasprzak jaro 2006 Na tomto místě bych rád poděkoval několika lidem, kteří mi pomáhali odbornou radou nebo s realizací této práce. Děkuji proto: Mgr. Janu Kasprzakovi, za úvod do vývoje v kernel-space Mgr. Lukášovi Hejtmánkovi, za konzultace a tipy Evgeniy Polyakovovi, autorovi programu connector za pomoc při řešení problémů První část této práce zkoumáme motivaci pro používání snapshotů a uvedeme přehled a srovnání jednotlivých variant v OS Linux. V druhé části práce implementujeme modul pro podporu snapshotů na VFS vrstvě operačního systému Linux. Linux kernel VFS filesystem snapshot S rostoucím množstvím uchovávaných a zpracovávaných dat se čím dál tím více potýkáme s problematikou, jak tyto data bezpečně zálohovat a jakým způsobem zajistit jejich konzistentnost. Nejběžnějším postupem pro zálohování dat je vytvoření kopie dat z jednoho disku nebo spíše diskového pole na jiné, nejčastěji však na páskovou mechaniku (streamer). Tento způsob zálohování přináší netriviální problémy. Nejčastějším problémem je rychlost zálohování - páskové mechaniky jsou totiž typicky řádově pomalejší než disková pole. I vytváření kopie mezi jednotlivými diskovými poli může trvat i několik desítek hodin v závislosti na objemu dat a typu propojení mezi diskovými poli. Nelze proto očekávat, že po dobu vytváření záloh budou všechny aplikace pozastaveny a nebude docházet ke změně dat. Řešením tohoto problému je vytváření tzv. snapshotůsnapshot (snímkůsnímek). Idea toho přístupu spočívá v tom, že ačkoliv je v daný časový okamžik celkový objem dat relativně velký, v průběhu času se mění jen malá část dat. Změnou dat v tomto kontextu chápeme i smazání nebo přidání dat. Tohoto empirického poznatku využijeme tak, že provedeme atomickou operaci "vytvoř snapshot". Tato operace pouze poznačí informaci o vytvoření snapshotu, jaké části dat se snapshot týká a kam se mají kopírovat případné zálohy původních dat v případě požadavku na jejich změnu. Následně mohou aplikace pokračovat v běžném provozu. Při požadavku na změnu dat dojde k pozastavení tohoto požadavku, následně se vyhodnotí, která data mají být změněna, následuje provedení zálohy původních dat. Teprve potom se provede požadavek na změnu dat. Tato technika se nazývá Copy-on-WriteCopy-on-Write. Stav dat v okamžiku provedení snapshotu se zrekonstruje pomocí aktuálních dat a odzálohovaných původních dat. S přihlédnutím k obsahu druhé části této práce, která se zabývá implementací snapshotů ve VFS vrstvě OS Linuxu, se v této kapitole zaměříme převážně na možnosti snapshotů v OS Linux. Copy-on-WriteCopy-on-Write Technika, kdy se vytvoří virtuální kopie dat a skutečná kopie dat se provádí až v okamžiku požadavku na změnu dat. Kernel-spaceKernel-space Označení programu běžícího jakou součást jádra operačního systému. Toto má za následek některá omezení (nelze používat žádné externí knihovny, jen funkce jádra) i možnosti (přímý přístup k jednotlivým zařízením a datovým strukturám a funkcím jádra). Z hlediska bezpečnostního i stability je snaha, aby v kernel-space běžela vždy jen ta nejmenší možná část projektu. Read-only snapshotRead-only snapshot Snapshot dat, který je k dispozici pouze pro čtení. Typické použití pro zálohování dat. Read-write snapshotRead-write snapshot Snapshot dat, kde můžeme data snapshotu dále měnit bez toho, aby byla změněna původní data. Typické použití pro správu více verzí dat. Někdy se nazývá tato vlastnost jako klonování (cloningcloning) dat. Roll-back snapshotuRoll-back snapshotu Operace, která uvede aktuální data do stavu v okamžiku snapshotu. Veškeré provedené změny dat od provedení snapshotu budou ztraceny. SnapshotSnapshot (snímek)Snímek Stav (obsah) dat v určitý časový okamžik. Často se jedná o virtuální obraz, který je skládán z více datových zdrojů. SyscallSyscall (systémové volání)Systémové volání Volání funkce jádra operačního systému user-space programem. Liší se velmi zásadně od volání jiné funkce user-space programu nebo knihovny - dochází ke změně kontextu přerušení a běh funkce je prováděn v privilegovaném režimu jádra. V OS Linux je doporučeno pokud možno vyvarovat se volání systémového volání z jiného systémového jádra nebo obsluhy přerušení. User-spaceUser-space Označení "standardního" programu. Program komunikuje s jádrem operačního systému pomocí tzv. systémových volání (syscall). VFSVFS (Virtual Filesystem Layer) Vrstva v OS mající na starosti primárně správu jednotlivých souborových systémů, předávání požadavku na práci se souborovým systémem, soubory a adresáři konkrétním souborovým systémům. Často se také stará o cachování převodu jména souboru nebo adresáře na ukazatel na konkrétní strukturu souborového systému. Blokovým zařízením rozumíme nejnižší možnou úroveň operačního systému přístupu k datům - typicky tedy disky, disková pole nebo různé speciální zařízení (RAM disky, síťové zařízení apod.). V OS Linux jsou snapshoty na úrovni blokových zařízení implementovány ve správě logických svazků (Logical Volume Management)Logical Volume Management. Mezi běžně používné nástroje ke správě logických svazků patří LVM2LVM2 (vyvíjený primárně firmou RedHat, je standardní součástí jádra Linuxu) a EVMSEVMS (vyvinutý firmou IBM, není součástí standardního jádra Linuxu). Obě tyto implementace poskytují z našeho pohledu stejnou funkčnost - možnost vytvořit read-only snapshot. Zatímco LVM2 umožňuje vytvořit snapshot pouze logických svazků, tak EVMS podporuje snapshoty pro veškeré typy objektů (disky, segmenty, oblasti a tzv. feature-objekty). EVMS také podporuje roll-back snapshotu. Hlavní výhodou snapshotů na úrovni blokových zařízení je jejich vysoká efektivnost. BLOCK Protože se pracuje s relativně malými bloky dat (typická velikost - 4 kB) je u typických aplikací dosaženo vysoké efektivity. Teoreticky je možné setkat se i se situací, že dojde ke změně několika málo bytů v mnoha blocích. V praxi se s tímto chováním nesetkáme především z toho důvodu, že souborové systémy také pracují s bloky v řádech kB a až na exotické vyjímky nikdy s jednotlivými byty. Relativní jednoduchost vede také k vysoké rychlosti a spolehlivosti této varianty snapshotů. Hlavní nevýhodou této varianty je, že je možné provést snapshot pouze celého blokového zařízení (disku, diskového pole, svazku apod.). Toto vyplývá z neznalosti vnitřní struktury dat (typicky souborového systému) a proto nelze provést snapshot pouze určité části dat (např. pouze aktuálního projektu). Na tuto skutečnost je nutné dbát už při počáteční instalaci systému a rozdělování úložného prostoru do svazků a souborových systémů. V podstatě neexistuje žádná jednoduchá možnost, jak následně toto rozdělení změnit. Jedna z možností je odzálohovat všechny data, změnit rozdělení logických svazků a data obnovit. Pokud to souborové systémy umožňují, je možné data postupně přesouvat a podle toho dynamicky měnit velikosti souborových systémů a svazků. Jedná se však o rizikovou činnost. Další nevýhodou můžeme spatřovat v tom, že u standardní implementace LVM2LVM2 je nutné při vytváření snapshotu specifikovat oblast, kam se budou postupně ukládat zálohovat původní datové bloky. Jakmile však je tato oblast zaplněna, není možné ji zvětšit, změnit ani přidat další oblast. Tento jev se může vyskytnout třeba v případě, že záloha trvá výrazně déle než byl původní odhad a/nebo dochází k častějším změnám dat. V implementaci EVMSEVMS je toto ošetřeno možností přidávat podle potřeby další datové oblasti. Z neznalosti vnitřní struktury dat vyplývá nutnost zajistit externími mechanismy konzistentnost dat v okamžiku vytvoření snapshotu. Například aby současně s prováděním snapshotu nebyl prováděn zápis do nějakého kritického souboru. V podstatě všechny moderní souborové systémy podporují funkci dočasného uzamčení souborového systému (tzv. "freeze") právě pro potřeby vytváření snapshotů. Tedy až na speciální aplikace (databáze apod. - více v kapitole ) lze tuto podmínku splnit. Protože jsou prováděny zálohy jednotlivých datových bloků, nelze tyto zálohy jakkoliv využít v případě výpadku aktuálního blokového zařízení. Taktéž nelze tyto odzálohované bloky nijak dále zpracovávat. Se systematickou podporou snapshotů v souborových systémech se setkáváma až v posledních několika letech. Nejprve s touto vlastností přišly souborové systémy WAFLWAFL (firma NetApp) a VxFSVxFS (firma Veritas). V současnosti jsou snapshoty plně podporovány v souborových systémech FossilFossil (experimentální OS Plan 9) PLAN9, ZFSZFS (OS Solaris 10), NTFSNTFS (OS Windows) a UFS2 (OS FreeBSD). Ze zajímavých vlastností bych rád upozornil na souborový systém Fossil, který je navržen tak, aby podporoval tvorbu snapshotů přímo jednotlivými uživateli. Mezi nejnovější souborové systémy patří ZFSZFS, který byl uveden v roce 2005 jakou součást nového OS Solaris 10. Nejedná se v pravém slova smyslu o čistě souborový systém, protože v sobě obsahuje i prvky správy logických jednotek (LVM). Díky tomuto heterogennímu modelu podporuje ZFSZFS jak read-only, tak read-write snapshoty. Za pomoci integrovaného správce logických jednotek provádí snapshoty na úrovni bloků a dosahuje vysoké efektivity read-write snapshotů. Souborový systém NTFSNTFS podporuje funkci Shadow CopyShadow Copy. Jedná se o funkci umožňující jednotlivým uživatelům vytvářet snapshoty jednotlivých adresářů. NTFS Znalost vnitřní struktury souborového systému (hlavičky, metadata, transakční logy) umožňuje větší úspornost snapshotů, kdy například nedochází k vytváŕení snapshotu pro transakční log. Taktéž je zajištěna vnitřní konzistenost dat. Kromě souborového systému NTFS žádný jiný souborový systém nepodporuje snapshoty konkrétního adresáře. Vždy je nutné provést snapshot celého souborového systému, což není vždy žádoucí.. Časté používání snapshotů souborového systému omezuje doposud také úzká provázanost s konkrétním OS. Tato kombinace konkrétního souborového systému a OS nemusí také vyhovovat pro všechny případy nasazení - např. různá jednoúčelová (embedded) zařízení. Každý souborový systém má vlastní filozofii tvorby snapshotů a nástroje na jejich správu. Žádná ze současných implementací snapshotů v souborovém systému nepodporuje možnost provádět kopírování snapshotovaných dat na jiný souborový systém. Nelze proto například ukládat data snapshotů na jiné úložiště dat připojené přes počítačovou síť. Snapshoty v souborových systémech provádějí (podobně jako snapshoty blokových zařízení) zálohy jednotlivých datových bloků, proto v případě ztráty původního souborového systému nelze z těchto datových bloků extrahovat žádnou konzistetntní informaci. Nelze provádět konzistentní snapshoty souborů otevřených pro zápis - více o této problematice v kapitole . Jde o technicky velmi zajímavý přístup. Je vytvořen virtuální souborový systém, který zobrazuje "pohled" na původní (primární) souborový systém a veškeré operace změn dat jsou přesměrovány do jiného (sekundárního) souborového systému. Tím dochází k zachování původního stavu primárního souborového systému. Nejedná se tedy v čistě formálním smyslu o snapshot. Z hlediska konečného efektu je důsledek stejný - dochází k zachování stavu primárního souborového systému při zachování možnosti provádět na tomto souborovém systému změny. Nedílnou součástí tohoto virtuálního souborového systému tvoří funkce nazývaná "filesystem union"filesystem union. Tato funkce umožňuje poskládat - sloučit - stav několik souborových systémů do jednoho virtuálního. Aktuální stav modifikovaného virtuálního souborového systému získáme sloučením primárního (původního) souborového systému a sekundárního systému. Jediný stávající souborový systém s touto funkcionalitou, je souborový systém UnionFSUnionFS UnionFS pro OS Linux. Tento souborový systém je hojně využíváný při tvorbě tzv. LiveCD/DVDLive CD/DVD. Primární souborový systém uložený na CD nebo DVD je k dispozici pouze pro čtení a tedy veškeré operace změn dat jsou přesměrovány buďto na ramdisk (a tedy po vypnutí stroje ztraceny) nebo třeba na USB memory stick, který umožní jejich zachování i po vypnutí systému. V případě změny jsou soubory a adresáře kopírovany jako celek. Dojde-li k výpadku primárního souborového systému, jsou stále tato data "smysluplná". Dále je tento přístup naprosto nezávislý na použitých souborových systémech. Zálohy původních změn souborů mohou být ukládány na libovolný souborový systém - tedy i na sdílený síťový souborový systém. Tato metoda přináší dvě zásadní nevýhody. Jelikož se jedná o práci na úrovni souborů, pak i v případě velmi malé změny dat dochází k provedení zálohy celého souboru. To může v některých případech vést k neúnosné časové náročnosti či dokonce nemožnosti tuto metodu použít - například v případě, kdy souborový systém obsahuje jeden nebo několik velmi velkých souborů. Záloha těchto souborů by v případě žádosti o jejich změnu byla v podstatě srovnatelná se zálohou celého souborového systému. Další nevýhodou je skutečnost, že pro vytvoření snapshotu je nutno připojit nový (virtuální) souborový svazek a přesměrovat veškeré aplikace z původního souborového systému na nový. V úvahu připadá také možnost stávající souborový svazek odpojit, připojit jej na jiné místo a následně místo něj připojit nový virtuální svazek. V každém případě je nutno dodržet podmínku, aby pro vytvoŕení snapshotu všechny aplikace uzavřely všechny soubory a to i takové, které jsou otevřeny pouze pro čtení a nemohou snapshot jakkoliv ovlivnit. Jedná se o kompromisní řešení mezi nativní podporou snapshotů přímo v souborovém systému a speciálním souborovým systémem určeným pouze pro snapshoty. Konkrétní implementace tohoto přístupu tvoří náplň druhé části této práce. Princip této techniky spočívá v zachytávání požadavků na změnu dat ve VFSVFS vrstvě operačního systému. Tyto pak následně vyhodnocuje na základě jména souboru/adresáře a typu požadované operace. V případě nutnosti provedení zálohy dat a je zpracování požadavku pozastaveno na dobu nutnou k vytvoření záložní kopie dat. Pro následné připojení a práci se snapshotem využívá tato konkrétní implementace virtuální souborový systém UnionFSUnionFS, který je pro tyto účely více než postačující. Díky jeho vlastnosti přesměrovávat změny na původních datech do jiného souborového systému lze dokonce vytvářet read-write snapshoty. Read-write snapshot vytvoříme provedením sjednocení původního (primárního) souborového systému a odzálohovaného (sekundárního) souborového systému vytvořeného ve VFS vrstvě. Výsledný pohled na souborové systémy připojíme pomocí UnionFSUnionFS a operace změny dat přesměrujeme do jiného (terciálního) souborového systému. Protože tato technika pracuje ve VFSVFS vrstvě OS, jedná se o metodu nezávislou na souborovém systému. Lze proto použít libovolný souborový systém. Tato technika, podobně jako speciální snapshotový souborový systém, kopíruje celé soubory a adresáře. Odzálohovaná data jsou tedy konzistetní a použitelná i v případě výpadku původního souborového systému. Tímto způsobem je zachována možnost provádět zálohu dat na libovolný souborový systém - tedy i na síťový svazek. Hlavním rozdílem a výhodou této metody oproti speciálnímu souborovému systému je, že po instalaci tzv. háčkůháčky (hookshooks) do jádra OS (a typicky následném rebootu) je možné aktivovat snapshoty pro libovolný souborový systém kdykoliv. Možné je následně provádět upgrade na novější verze bez nutnosti rebootu. Háčky v jádře jsou navrženy tak, aby neovlivňovaly funkce a výkon jádra v případě, že nejsou snapshoty aktivní či dokonce není příslušný SW nainstalován. Konkrétní implementace demonstrovaná v druhé části práce podporuje snapshoty na úrovni adresářů. Jedná se tedy kromě podpory v souborovém systému NTFSNTFS o jedinou možnost, jak provádět snapshoty konkrétního adresáře bez nutnosti odpojovat a znovu připojovat celý souborový systém. Narozdíl od NTFSNTFS je zde možné provádět zálohu dat na libovolný jiný souborový systém, tedy i datové úložiště. Jedinou významnou nevýhodu tohoto přístupu (podobně jako u speciálního snapshotového souborového systému) lze nalézt v tom, že v případě změny dat se provádí kopie kompletního souboru se všemi důsledky z toho plynoucími (více viz kapitola ). Konkrétní implementace snapshotů ve VFSVFS provádí kopii souboru pokaždé, když je soubor otevřen pro zápis, bez dalšího zkoumání, zda skutečně dojde ke změně obsahu souboru. Tato vlastnost a možnost nápravy diskutujeme v sekci . Existuje několik typů aplikací, pro které nelze nebo je neefektivní použít doposud evedené metody snapshotů. Nejčastěji se jedná o databázové aplikace nebo třeba o emailové servery. Aplikace používá relativně velké soubory Tato vlastnost způsobuje nemožnost použít snapshoty na úrovni VFS vrstvy nebo speciální snapshotový souborový systém. Lze použít snapshoty na úrovni blokového zařízení nebo souborového systému. Nejčastěji se jedná o databázový SW nebo emailový server. Aplikace vyžaduje neustále otevřené soubory Tato situace může nastat v okamžiku, kdy nelze přerušit běh aplikace pro vytvoření snapshotu. Tato vlastnost způsobuje nemožnost použít snapshoty na úrovni VFS vrstvy nebo speciální snapshotový souborový systém. Lze použít snapshoty na úrovni blokového zařízení nebo souborového systému, pokud souborový systém podporuje snapshoty otevřených souborů. Nutnou podmínkou je i podpora aplikace pro uvedení všech otevřených souborů do stavu, kdy je možné snapshot provést - tedy typicky vyprázdnění všech vnitřních bufferů, dokončení probíhajících transakcí a/nebo podporu žurnálužurnál (journaljournal) v aplikaci. Nejčastěji se jedná o databázový SW, emailový server nebo SW, který má na starosti monitoring nebo kolekci logů. Vlastní/žádný souborový systém aplikace Aplikace nepoužívá žádný standardní souborový systém a přistupuje přímo k blokovým zařízením. Lze potom využít pouze snapshoty na úrovni blokových zařízení. I zde je nutná podmínka taková, že aplikace musí podporovat uvedení dat na blokovém zařízení do konzistentního stavu, aby bylo moźné snapshot provést. Typickou aplikací, která využívá vlastní souborový systém, je databáze Oracle. Tyto problémy řeší zabudovaná interní podpora snapshotů v aplikaci a propojení s modulem zálohovacího SW. Většinou se jedná o komerční řešení určené pouze pro danou konkrétní aplikaci a zálohovací SW. Díky kompletní znalosti struktury dat lze provádět optimální snapshoty dat a zálohovat pouze skutečně změněná data (nedochází např. k zálohování pomocných tabulek). Základní nevýhodou je nutnost existence příslušného modulu pro danou aplikaci, zálohovací SW a kombinaci OS a HW (platformu). Tyto moduly nemusí být nutně k dispozici pro všechny verze a jsou také často finančně velmi náročné. Vzhledem k tomu, že se téměř vždy jedná o komerční řešení bez zdrojových kódů a popisu datových struktur, odzálohovaná data nejsou použitelná pro žádné další zpracování. Snapshoty nejsou pochopitelně řešení postihující veškeré možné požadavky na zálohování dat. Jelikož se však jedná o vyzrálé produkty pracující na všmožných vrstvách, ve kterých pracujeme s daty, nesetkáme se v praxi téměř s takovou situací ve které by nešla použít některá ze zmíněných variant snapshotů. Nežádoucí dopad na výkon Aplikace může vyžadovat takovou rychlost provádění operací, že není možné čekat na kopírování dat při požadavku na jejich změnu. Typickým příkladem jsou tzv. real-time aplikace (řízení průmyslových a technologických procesů, zdravotnictví apod.). Příliš mnoho změn Základní idea snapshotu je ta, že většina požadavků na práci s daty je čtení existujících dat. V případě aplikací, kde je tomu naopak a aplikace mění příliš mnoho dat příliš rychle, tak vzrůstá neúměrně prostorová nebo časová složitost na tvorbu záloh dat. VFSVFS vrstva ZEN v OS Linux má na starosti tyto úkoly: Registraci jednotlivých souborových systémů, jejich připojování a odpojování. Převod jména souboru/adresáře na i-uzeli-uzel (i-nodei-node), který jednoznačně soubor/adresář identifikuje v rámci daného souborového systému. Cachování výsledků převodů jména souboru/adresáře na i-uzel. Obsluhu systémových volánísystémové volání (syscallsyscall) souvisejících se souborovými systémy a v případě potřeby převod těchto volání na nativní volání konkrétního souborového systému.

Analýza i následná implementace je prováděna na jádře OS Linux řady 2.6, konkrétně verze 2.6.16. Motivací pro detailní zkoumání systémového volání je to, že se jedná o jediný způsob, jak volají programy jednotlivé funkce jádra. Proto pokud chceme zjistit požadavek na změnu dat souboru/adresáře před tím, než bude změna provedena, musíme takovéto systémové volání nějakým způsobem odchytit, vyhodnotit a případně pozastavit na dobu provedení kopie původních dat. Každé systémové volání je identifikováno jednoznačným číslem volání. Tabulka systémových volání je pro každou architekturu jiná, pro architekturu x86 je uvedena v souboru arch/i386/kernel/syscall_table.S. Pokud chce program provést systémové volání, uloží na zásobník aktuální stav registrů, parametry, číslo systémového volání a vyvolá softwarové přerušení. Jádro převezme ze zásobníku parametry systémového volání a podle tabulky systémových volání zavolá příslušnou funkci. Poté převezme návratovou hodnotu, uloží ji na zásobník a vrátí řízení zpět původnímu programu. Ten převezme ze zásobníku návratovou hodnotu systémového volání, obnoví ze zásobníku stav registrů a pokračuje v běhu. V předchozí řadě jádra OS Linux (řada 2.4) byla tato tabulka systémových volání dostupná a modifikovatelná v rámci celého jádra. Toto umožňovalo nahradit příslušné systémové volání vlastním - např. pro účely auditu zaznamenat informace o volání a pak použít původní volání. Z bezpečnostních důvodů nelze v aktuální řadě jádra systémová volání přesměrovávat, takže v případě, kdy potřebujeme zachytit nějakou operaci (v našem případě požadavek na změnu souboru/adresáře), je nutno použít jinou metodu. Jedinou korektní metodou, jak v současném jádře zachytit systémová volání, je modifikace funkcí, které přímo obsluhující jednotlivá systémová volání. Konkrétní implementace modifikace systémových volání je probírána v kapitole . Jak již bylo řečeno v úvodu kapitoly, VFSVFS vrstva slouží nejenom k zajištění operací související se souborovými systémy a soubory/adresáři samotnými. Má na starosti i implementaci konkrétních systémových volání a cachování výsledků převodu jména na i-uzeli-uzel. Tato cache je nazývána "dcache"dcache a je implementována v souboru fs/dcache.c. Převod jména na konkrétní i-uzel je totiž často časově náročný, proto dcache výrazně urychluje práci se souborovým systémem. Převod jména na položku dcache zajištuje funkce path_lookup (definována v souboru fs/namei.c), která používá stukturu nameidata (definována v souboru include/linux/namei.h) obsahující ukazatel do dcache a ukazatel na přípojný bod souborového systému s daným souborem. Při práci s i-uzly (a tedy i dcache) je nutno mít na paměti, že zatímco převod jména na i-uzel je jednoznačný, nelze k i-uzlu dohledat jednoznačně jméno souboru/adresáře. Toto je způsobeno existencí linkůlink a také tím, že ačkoliv soubor může už být vymazán. Dokud jej má některá aplikace otevřený, existuje nadále jako i-uzel. Na základě provedené analýzy bylo doporučeno rozdělit systém do několika funkčních celků (více viz kapitola ). Základním principem při implementaci by měla být snaha přesunout maximum funkčnosti z funkcí jádra do jaderného modulu nebo do user-space programu. Důvodem je snaha minimalizovat případný dopad potenciálních chyb na stabilitu a bezpečnost zbytku jádra operačního systému. Pro komunikaci mezi user-spaceuser-space a kernel-spacekernel-space bude použit program "connectorconnector". Jedná se o součást standardního jádra speciálně určenou právě pro předávání zpráv mezi user-space a kernel-space. Tento program pracuje na principu zasílání datagramůdatagram, jedná tedy se o bezestavový protokol bez zaručení doručení zprávy. Více informací o konkrétní implementaci a omezeních je v kapitole . Při implementaci je také nutno brát v úvahu vznik race-condition, a proto je nutné potencionálně kritická místa ochránit zámky. Je proto využita relativně nová implementace tzv. mutexůmutex. Jedná se o nový typ zámku podporující pouze jednoduché uzamčení, odemčení a test na to, zda je zámek zamknutý. Narozdíl od jiných typů zámků (semafor, read-write zámek) je výrazně rychlejší. Pokud nejsou snapshoty ve VFS vrstvě aktivovány, mělo by docházet k žádnému nebo alespoň k co nejmenšímu možnému zpomalení všech operací jádra. V případě, že jsou snapshoty aktivní, měla by kopie dat být provedena co nejpozději. Nejlépe až po vyhodnocení, že daná operace změny dat se skutečně týká souboru/adresáře, který se má snapshotovat a že neselže na nedostačujících uživatelských právech nebo jiných okolnostech. Dle provedené analýzy byla implementace rozdělena do několika oddělených funkčních celků. Celý projekt je nazván vfs_cowvfs_cow jako akronym pro VFS Copy-On-Write. Jedná se úmyslně o velmi jednoduchý a přehledný kód ve formě tzv. patchepatch. Tento patch je vytvořen přímo pro určitou verzi jádra. Pokud chce uživatel použít jinou verzi jádra, může tento patch být použitelný beze změny, vyžadovat malou úpravu nebo zcela novou implementaci. VFS vrstva v OS Linux je za posledních několik let velmi stabilní a dochází zde s časem spíše pouze k drobnému vyčištění kódu, malým optimalizacím (konkrétně v poslední době převod řady tzv. semaforůsemafor na mnohem rychlejší variantu zamykání - tzv. mutexymutex), což by mělo umožnit použitelnost patche i pro budoucí verze. Dlouhodobým cílem je, aby byl tento patch začleněn do standardní verze jádra tak, aby zmizela nutnost patchovat jádro úplně. Úprava VFS vrstvy se skládá ze 2 částí. První z nich je přidání nových souborů fs/vfs_cow.c a include/linux/vfs_cow.h deklarující základní funkce a proměnné. Ačkoliv se jedná o velmi malou část z celkového programu (pouze 200 řádků kódu) je tato část pro pochopení celé implementace kritická. Proto jí budu věnovat zvýšenou pozornost v následujícím textu. int vfs_cow_loadedvfs_cow_loaded Tato proměnná je nenulová v případě, když je načten modul vfs_cowvfs_cow (viz kapitola ). Ukazatele na funkce modulu Zde jsou definovány ukazatele na funkce vfs_cow_prepare_functor, vfs_cow_submit_functor a vfs_cow_commit_functor. Modul vfs_cow při svém inicializace přesměruje tyto ukazatele na vlastní funkce. rwlock_t vfs_cow_rwlockvfs_cow_rwlock Jedná se o tzv. read-write zámek. Read zámek může držet více procesů najednou, zatímco write zámek může držet pouze jeden proces a po tuto dobu nemůže být aktivní ani žádný read zámek. Tento zámek slouží k prevenci race-condition. Race-condition by mohla nastat v okamžiku, kdy jeden proces vyhodnotí proměnnou vsf_cow_loaded jako načtený příslušný modul. V tento okamžik by došlo k přerušení provádění tohoto procesu a jiný proces by odstranil modul vfs_cow z paměti. Při obnovení běhu prvního procesu by došlo k volání ukazatele na funkci již neexistujícího modulu. Proto nejprve získáme read zámek, provedeme vyhodnocení, zda je modul načten a případně voláme příslušnou funkci modulu. Teprve po ukončení tohoto volání zámek uvolníme. V případě, že chceme modul odstranit z jádra, musíme nejprve získat write zámek. Tento postup zaručuje, že s tímto modulem nepracuje v daný okamžik žádný jiný proces. Tento zámek nelze z výkonostních důvodů nahradit mutexem. Použití mutexu by mělo za následek serializaci požadavků na modul jádra, zatímco read-write zámek umožnuje libovolný současný počet read zámků - tedy volání funkcí modulu. int vfs_cow_prepare (const char *filename, const char *dst, int syscall)vfs_cow_prepare Tato funkce je volána až když dojde k vyhodnocení syscallu, že může dojít ke změně dat (např. je požadavek na otevření souboru pro čtení i zápis). Parametry této funkce jsou jméno souboru (parametr filename), typ systémového volání (parametr syscall) a v případě systémového volání rename i cíl (parametr dst). Smyslem této funkce je pouze vytvoří v modulu nový požadavek (typ cow_requestcow_request - viz kapitola ), následná inicializace proměnných a normalizace cest souborů (tzn. v případě relativní cesty se převede na absolutní, dojde k odstranění adresářových položek typu "/../" a "/./". Funkce nevyhodnocuje, zda požadavek se týká snapshotováných dat. Požadavek je poté uložen do oboustranně zřetězeného seznamu a řízení je vráceno obsluze syscallu. int vfs_cow_submit (void)vfs_cow_submit Tato funkce je volána poté, co dojde k detailnějšímu vyhodnocení syscallu (jsou ověřena přístupová práva, existence/neexistence požadovaného souboru apod.) a to těsně před tím, než je zavolána proprietární funkce konkrétního souborového systému. Pokud proces nemá například dostatečná užitelská práva, nebude tato funkce vůbec volána a bude rovnou volána funkce vfs_cow_commit s příslušným číslem chyby. V tento okamžik dojde k vyhodnocení toho, zda je požadovaný soubor/adresář součástí nějakého aktivního snapshotu. Pokud ano, vygeneruje se požadavek na vytvoření záložní kopie a aktuální proces se na dobu nutnou k vytvoření kopie uspí. Tato funkce nevyžaduje žádný parametr. Pro identifikaci požadavku využáme skutečnosti, že jeden proces může v jeden okamžik vykonávat pouze jeden syscall a syscally se nemohou vnořovat, takže příslušný požadavek snadno nalezneme v seznamu požadavků podle aktálního PIDPID (process ID). Teoreticky by bylo možné funkce vfs_cow_prepare a vfs_cow_submit sloučit do jedné. V praxi však jsou často volány z různých funkcí a bylo by nutno je zásadněji upravit funkce VFS vrstvy. Často už v okamžiku volání funkce vfs_cow_submit neznáme původní jméno souboru, ale už přímo konkrétní i-uzeli-uzel. Následné volání funkce souborového systému může z mnoha různých důvodů skončit chybou a změny nemusí být provedeny. Záložní kopie souboru tedy byla provedena zbytečně. Tuto situaci však nelze na úrovni VFS jakkoliv předpokládat - museli bychom upravovit příslušná volání veškerých souborových systému v Linuxu a funkci vfs_cow_submit volat až přímo z nich. int vfs_cow_commit (int error)vfs_cow_commit Tato funkce je volána po dokončení volání souborového systému. Parametr "error" určuje, zda došlo při tomto volání k chybě (nenulová hodnota) nebo vše proběhlo v pořádku. V současné implementaci je reakce na obě situace identická - dojde k odstranění příslušného požadavku ze seznamu požadavků. V budoucích verzích by bylo možné v případě chyby odstranit vytvořenou záložní kopii souboru/adresáře aby nezabírala diskový prostor. Dále by bylo vhodné zaznamenávat informaci o tom, které volání selhalo s jakou chybou na kterém souboru/adresáři pro pozdější vyhodnocení.

Tento modul udržuje seznamy požadavků předávaných VFS vrstvou a vyhodnocuje, zda je nutné provést zálohu dat. Následně předává tento požadavek user-space programu vfs_cowdvfs_cowd. Z tohoto důvodu udržuje seznam požadavků (cow_requestscow_requests), prefixů (cow_prefixescow_prefixes) a požadavků na zálohu dat (cow_catchescow_catches). Tyto seznamy jsou podrobněji popsány v kapitole Při zavedení modulu nejprve modul nastaví ukazatele na příslušné funkce (viz kapitola ) poté získá write zámek na vfs_cow_rwlockvfs_cow_rwlock, nastaví proměnnou vfs_cow_loadedvfs_cow_loaded na 1 a uvolní zámek. Při odstraňování modulu postupuje opačně - nejprve získá write zámek, nastaví proměnnou vfs_cow_loadedvfs_cow_loaded na 0, uvolní zámek a vynuluje ukazatele na jednotlivé funkce. Protože jakékoliv jiné procesy mohou přistupovat k proměnné proměnnou vfs_cow_loadedvfs_cow_loaded pouze s read zámkem, je zajištěno, že pokud takovýto proces získá tento zámek, zůstanou ukazatele na funkce platné po celou dobu platnosti read zámku. Tento jaderný modul také integruje procfsprocfs rozhraní pro monitorování stavu modulu (více v kapitole ). Předávání zpráv do user-space pro zpracování a naopak příjem zpráv o provedení zálohy dat je prováděn pomocí programu connectorconnector (více v kapitole ). prefixprefix Záznam o tom, který adresář se má monitorovat na změny a kam se mají provádět případné zálohy dat. Počet těchto záznamů není nijak omezen. Může zde být i více požadavků na monitorování jednoho adresáře nebo dokonce můžou být tyto požadavky vnořené. Administrátor musí pouze dbát na to, aby nedošlo k rekurzi, kdy by se proces vytváření záloh zacyklil. requestrequest Jedná se o záznam o prováděném syscallu, který obsahuje typ syscallu, typ operace a jméno souboru/adresáře. Je zde také uloženo počet vytvořených požadavků na zálohu tohoto souboru/adresáře. catchcatch Záznam o požadavku na vytvoření záložní kopie. Obsahuje ukazatele na příslušné záznamy prefix a request. Pro větší výkon kontroluje modul před odesláním požadavku na vytvoření záložní kopie, zda nebyla tato kopie již někdy v minulosti vytvořena. Kontroluje se také, zda v případě modifikace/smazání souboru/adresáře se nejedná o soubor/adresář, který nebyl vytvořen až po provedení snapshotu. V tomto případě také není provedena záloha tohoto souboru/adresáře. Program vfs_cowdvfs_cowd má na starosti příjem zpráv od jaderného modulu (tzv. "catch"catch), vytvoření záložní kopie původních dat a následné zaslání zprávy jadernému modulu a ten může pokračovat v obsluze pozastaveného syscallu. Z důvodu maximalizace výkonu a portability jsou v tomto programu implementovány funkce na kopírování souborů, symbolických linků, speciálních souborů (bloková nebo znaková zařízení), adresářů a synchronizaci rozšířených atributů namísto volání stávajících programů Linux. Pro zvýšení výkonu systému se provádí po přijetí požadavku na vytvoření záložní kopie fork, takže v jeden okamžik můźe probíhat libovolný počet zálohování souborů/adresářů. Program vfs_cow_adminvfs_cow_admin je nástroj pro administrataci nastavení snapshotů. Umožňuje přidávat a odebírat z jaderného modulu tzv. prefixyprefix, tedy které adresáře se mají monitorovat na změny a kam se případné zálohy původních souborů mají provádět. Dále umožňuje pro účely ladění a testování označit požadavky na kopírování dat (tzv. "catch"catch) jako ukončené. Umožňuje také zavolat funkci jaderného modulu, která vyprázdní veškeré vnitřní seznamy požadavků, prefixů nebo požadavků na kopii dat (catch). Pro sledování stavu systému je v jaderném modulu implementováno procfsprocfs rozhraní. Při načtení jaderného modulu jsou vytvořeny virtuální soubory /proc/fs/vfs_cow/catches, /proc/fs/vfs_cow/prefixes, /proc/fs/vfs_cow/requests a /proc/fs/vfs_cow/version. Obsah těchto souborů je dynamicky generován při každém požadavku čtení a reflektuje aktuální stav vnitřních seznamů jaderného modulu, resp. verzi modulu (/proc/fs/vfs_cow/version). Program "vfs_cowdvfs_cowd" lze spustit s parametrem -v, což aktivuje podrobné výpisy o jednotlivých prováděných krocích. Komunikace mezi háčky v kernelu a jaderným modulem je zprostředkována pomocí ukazatelů na funkce jaderného modulu (viz kapitola ). Komunikace mezi jaderným modulem a mezi user-space programy vfs_cow_adminvfs_cow_admin a vfs_cowdvfs_cowd je realizována pomocí programu connectorconnector. Jedná se o program určený speciálně pro jednoduché, bezestavové, zasílání datagramů mezi user-space a kernel-space. Každá zpráva je identifikována pomocí dvojice identifikátorů - čísla skupiny (značícího třídu zprávy) a čísla typu zprávy. Každý typ programu, který chce komunikovat tímto způsobem by si měl zvolit jedinečný identifikátor čísla skupiny. Identifikátor typu zprávy je pomocný a není v této implementaci využíván, protože zprávy jsou vždy jen jednoho typu. Při volání jednotlivých funkcí jaderného modulu z funkcí obsluhy syscallu je prováděna modulem kontrola, zda lze zasílat zprávy do user-space - tedy, zda je aktivní nějaký příjemce (program vfs_cowdvfs_cowd). Pokud není aktivní žádný příjemce, nelze jakýkoliv požadavek zpracovat, proto je řízení vráceno syscallu, aby nedošlo k nežádoucímu uváznutí procesu. Program connector má v současnosti několik omezení - nelze zasílat z user-space do kernel-space zprávy větší než 1 kB (opačným směrem lze zasílat zprávy libovolné velikosti). Dále není možné potvrdit příjem a/nebo zpracování zprávy příjemcem nebo jednoduše vrátit návratovou hodnotu. V této části bych se rád podrobněji zmínil o hlavních použitých datových strukturách. Tato datová struktura slouží k zasílání zpráv pomocí programu connectorconnector mezi user-space a kernel-space. id ID zprávy nebo prvku v seznamu, jehož se zpráva týká (dle hodnoty proměnné "type"). len Celková délka zprávy. type Typ zprávy (přidání prefixu, potvrzení provedení zálohy apod.). action Typ změny dat v případě požadavku na zálohu dat - např. vytvoření nového soubou, změna souboru, změna atributů, smazání souboru apod. catch_number V případě většího počtu požadavků na zálohování stejného souboru/adresáře do více cílů je zde uloženo pořadové číslo požadavku. catch_count Celkový počet požadavků na zálohování tohoto souboru/adresáře. match_prefix_id V případě požadavku na zálohování je zde uloženo ID prefixu, který tento požadavek vytvořil. prefix_len Délka prefixu v proměnné path. strings_len Součet délek řetězců v proměnných path a dst. Jedná se o kontrolu integrity, zda byla zpráva přijata v pořádku celá. path V případě požadavku na vytvoření zálohy souboru je zde uloženo jméno souboru/adresáře, jenž chceme zálohovat. V případě požadavku na vytvoření prefixu je zde uloženo, který adresář budeme monitorovat na změny (který adresář chceme snapshotovat). dst V případě požadavku na vytvoření zálohy souboru je zde uložen cílový soubor/adresář kam se má soubor/adresář odzálohovat. V případě požadavku na vytvoření prefixu je zde uložen cílový adresář pro ukládání odzálohovách souborů/adresářů. Tato datová struktura uchovává informace o prefixuprefix (adersářích, který se mají snapshotovat). node_list Struktura zajištující začlenění prvku do oboustranně zřetězeného seznamu. id ID prefixu. timestamp Čas přidání prefixu. path Prefix (adresář, který se má snapshotova). dst Cílový adresář, kam se mají ukládat odzálohované soubory. Tato datová struktura uchovává informace o požadavcích (requestrequest) vytvářených z obsluhy jednotlivých syscallů. node_list Struktura zajištující začlenění prvku do oboustranně zřetězeného seznamu. id ID požadavku. pid Číslo procesu, který vytvořil požadavek. syscall Označení typu syscallu, který vytvořil požadavek. action Typ požadované změny (vytvoření nového souboru, změna stávajícího souboru apod.). submitted Označuje, zda byl již požadavek potvrzen a má se provést záloha dat. done Označuje, zda je požadavek na zálohu dat již proveden. timestamp Čas vytvoření požadavku. waitq Čekací fronta (wait queuewait queue). Slouží k uspání procesu po dobu vyřízení požadavku na zálohu dat). wait Prvek čekací fronty. catches Počet vytvořených požadavků na zálohu dat. V případě vytvoření požadavku na změnu dat je procesu je zde uložen jejich počet a aktuální proces je uspán dokud zde je kladné nenulové číslo. Jedná se o speciální typ proměnné, která podporuje atomické operace, takže při zvýšení/zmenšení čísla o jedničku není potřeba zajištovat zamykání pro prevenci race-condition (např. pomocí mutexů). path Cesta k souboru/adresáři, který se má zálohovat. Tato datová struktura uchovává informace o požadavcích na zálohu dat (catchcatch). node_list Struktura zajištující začlenění prvku do oboustranně zřetězeného seznamu. id ID požadavku na zálohu dat. timestamp Čas vytvoření požadavku na zálohu dat. request Ukazatel na příslušný požadavek. match_prefix Ukazatel na příslušný prefix snapshotu. Cílem této práce bylo prozkoumat různé varianty snapshotů na různých úrovních zpracování dat. Následně na základě analýzy provést implementaci snapshotů do VFS vrstvy OS Linux. Srovnáním variant jsme dospěli k závěru, že každá varianta snapshotů má své výhody a nevýhody a je velmi odvislé od konkrétního nasazení, kterou zvolit. Přínosem této práce byl jak ucelený přehled variant snapshotů usnadňujících uživateli vybrat na základě konkrétních požadavků tu správnou, tak primárně vytvoření implementace snapshotů ve VFS vrstvě OS Linux. Dlouhodobým cílem je zveřejnění provedené implementace, získání zkušeností s jejího nasazení v různých prostředích a snaha o její začlenění do standardní distribuce jádra OS Linux. Z konkrétních změn by bylo dobré provést případné další optimalizace vytváření záloh dat, aby v případě kopírování souboru na více míst byly požadavky (catch) sloučeny a soubor byl čten jenom jednou. Dále v případě otevření souboru pro zápis by se měla vytvořit záložní kopie až teprve v okamžik, kdy je skutečně proveden zápis do souboru. Další vhodnou optimalizací by byla úprava virtuálního souborového systému UnionFSUnionFS tak, aby v případě změny metadat souboru (přístupová práva, vlastník souboru apod.) nebylo nutné provádět zálohu celého původního souboru. UnionFS C. P. Wright J. Dave P. Gupta H. Krishnan D. P. Quigley E. Zadok M. N. Zubair ACM Transactions on Storage (TOS) 2006 ZEN C. P. Wright R. Iyer N. Joukov N. Sivathanu E. Zadok ACM Transactions on Storage (TOS) 2006 BLOCK M. D. Flouris A. Bilas Proceedings of the 12th NASA Goddard 21st IEEE Conference on Mass Storage Systems and Technologies 2004 PLAN9 ATT Bell Laboratories 1995 NTFS Microsoft Corporation 2004 http://msdn.microsoft.com/data/winfs Kompletní implementace je licencována pod licencí GPL v2. Pro instalaci háčků do jádra OS je stačí v spustit v hlavním adresáři se zdrojovými kódy (typicky /usr/src/linux) příkaz cat /usr/src/vfs_cow/kernel_patches/2.6.16-rc1-mm2.patch | patch -p1 (kde /usr/src/vfs_cow/kernel_patches/2.6.16-rc1-mm2.patch je cesta k příslušnému patchi jádra) Pro kompilaci jaderného modulu by mělo postačovat spustit v adresáři se zdrojovými kódy projektu příkaz make mods. Kompilace vyžaduje korektně nainstalované kernel s podporou modulu a s aplikovaným patchem háčků. Pro zavedení modulu lze použít příkaz make load. Pro kompilaci programů ho modulu by mělo postačovat spustit v adresáři se zdrojovými kódy projektu příkaz make progs. Pro monitorování adresáře /opt/SRC a ukládání odzálohovaných souborů do adresáře /opt/DST stačí spustit v adresáři se zdrojovými kódy projektu příkaz usr/vfs_cow_admin -a /opt/SRC -p /opt/DST. Aby se začaly vytvářet záložní kopie, musí být spuštěný program usr/vfs_cowd Pro následné připojení vytvořeného snapshotu se použije připojení pomocí souborového systému UnionFS. Je nutné mít příslušný modul s tímto souborovým systémem zkompilovaný. Pro připojení vytvořeného snapshotu z předchozího odstavce se spustí příkaz: mount -t unionfs -o ro,dirs=/opt/DST=ro:/opt/SRC=ro,delete=whiteout unionfs /mnt/snapshot