NFS - III.

V minulém dílu jsme se začali podrobněji zabývat tím, jak protokol NFS (Network File System) ve skutečnosti pracuje. Probrali jsme si princip komunikace klienta se serverem, pokud jde o způsob určování konkrétních souborů a adresářů - prostřednictvím systémových identifikací, a nikoli prostřednictvím jmen a přístupových cest k souborům. Dnes pokročíme ještě dále a naznačíme si, jaké je postavení systémových identifikací (a protokolu NFS obecně) v rámci operačního systému počítačů v roli klientů i serverů.

Jelikož se naše dosavadní povídání o protokolu NFS týkalo především charakteru komunikace mezi klientem a serverem (neboli toho, co si vzájemně předávají, co od sebe požadují a co si poskytují), tedy jejich "vnějšími" projevy, nemuseli jsme náš výklad vztahovat k některé konkrétní systémové platformě, na které může být protokol NFS implementován. Jakmile se ale začneme podrobněji zabývat postavením NFS v rámci operačního systému, naše povídání již přestane být nezávislé na konkrétní platformě. Proto si musíme některou platformu vybrat, a vše potřebné si ukázat na jejím konkrétním příkladu (s naznačením odlišností pro jiné platformy). Nejvhodnějším platformou jistě bude prostředí, ve kterém protokol NFS vznikl, a ze kterého se pak rozšířil i na jiné platformy - tedy operační systém Unix.

Unix používá INODES

Jestliže protokol NFS má zajišťovat plně transparentní sdílení souborů (v tom smyslu, jaký jsme si zavedli již v 70. dílu), pak pro aplikační programy nesmí existovat žádný viditelný rozdíl mezi místními a vzdálenými soubory.

Obr. 77.1.: Představa rozhraní INODE (bez NFS)

V prostředí operačního systému Unix pracují aplikační úlohy se soubory způsobem, který ukazuje obrázek 77.1. - prostřednictvím systémových volání (system calls), které směřují do jádra operačního systému (kernel), a přes něj pak do systému souborů (file system). To je tvořeno společnou částí, nezávislou na konkrétním druhu souborů, a dále různými ovladači, které již jsou implementačně závislé. Mezi těmito dvěma vrstvami je pak rozhraní, ve kterém se nachází datové struktury, popisující jednotlivé soubory - tzv. INODES (od: Information Nodes, někdy též: Index Nodes). V těchto datových strukturách jsou obsaženy například informace o přesném umístění souboru či adresáře, o jeho velikosti, vlastníkovi, o přístupových právech apod. Přesný význam i repertoár těchto informací je však "šit na míru" jednomu konkrétnímu způsobu uchovávání místních souborů, zatímco vzdálené soubory, sdílené prostřednictvím sítě, vyžadují přeci jen něco jiného. Odlišnosti zde sice nejsou nijak velké, ale na druhé straně zase nejsou zanedbatelné a stačí na to, aby datové struktury INODE nebyly příliš vhodné pro současné reprezentování jak místních, tak i vzdálených souborů.

Rozhraní VFS/VNODE

Firma Sun, která protokol NFS vyvinula, vyřešila celý problém následujícím způsobem: rozhraní, ve kterém se nachází datové struktury INODE, "obalila" ještě jednou vrstvou - nazývanou Virtual File System (VFS) / Virtual File Node (VNODE) interface, a původní datové struktury INODE "překryla" poněkud obecnějšími datovými strukturami, které již mohou reprezentovat jak vzdálené soubory, tak i soubory místní. Tím ještě důsledněji oddělila společnou část systému souborů (nezávislou na konkrétní implementaci) od její implementačně závislé části. Výsledný efekt je takový, že nové rozhraní VFS/VNODE, vložené mezi obě tyto části, může být jednotné i v případě, kdy "překrývá" různě implementované systémy souborů - a to nejen vzdálené soubory, sdílené prostřednictvím protokolu NFS, ale také například místní soubory, uchovávané podle "zvyklostí" různých operačních systémů, v rámci kterých je protokol NFS implementován.

Jestliže tedy dříve pracovala společná část systému souborů přímo s rozhraním, obsahujícím struktury INODE (a označovaným jako "rozhraní INODE"), nyní již pracuje pouze s rozhraním VFS/VNODE a s datovými strukturami, které jsou v tomto rozhraní obsaženy. Původní struktury INODE sice nadále existují, ale systémová volání se k nim neobracejí přímo (ale pouze zprostředkovaně, přes datové struktury v rozhraní VFS/VNODE). V prostředí Unixu to samozřejmě znamenalo změnit všechna systémová volání, která zajišťují práci se soubory. Na druhé straně však toto řešení vyšlo vstříc nejen potřebám sdílení vzdálených souborů, ale také různým způsobům implementace souborových systémů v nejrůznějších "příchutích" Unixu (které mohou používat poněkud odlišné struktury INODE, a jednotné struktury v rozhraní VFS/VNODE).

Datové struktury VFS a VNODE

Obr. 77.2.: Vztah datových struktur VFS a VNODE

Datové struktury, obsažené v novém rozhraní, se jmenují příznačně: VFS a VNODE. Struktura VFS reprezentuje jeden konkrétní systém souborů jako takový, zatímco datová struktura VNODE je zobecněním struktury INODE, a reprezentuje jeden konkrétní soubor či adresář. Struktura VFS je vytvářena v rámci připojení souborového systému pomocí operace mount (viz 74. díl). Současně s tím je vytvářena i jedna struktura VNODE, reprezentující uzel adresářového stromu, ke kterému je dotyčný souborový systém připojován (viz obr. 77.2.). Další struktury VNODE jsou pak vytvářeny při otevírání jednotlivých souborů (a adresářů) v rámci příslušného souborového systému, a zařazovány do spojového seznamu struktur VNODE, sdruženého s příslušnou strukturou VFS - viz opět obrázek 77.2.

RNODE vs. INODE

Datovou strukturu VNODE je nejlépe chápat jako společné "zastřešení" datových struktur, které již jsou závislé na konkrétní implementaci. Za tímto účelem obsahuje struktura VNODE ukazatel na datovou strukturu, která příslušný soubor či adresář skutečně reprezentuje, a se kterou jsou také sdruženy výkonné procedury, zajišťující nejrůznější akce s příslušným souborem či adresářem. V případě místního souboru je takovouto strukturou původní datová struktura INODE (a ukazatel v rámci struktury VNODE pak ukazuje na exemplář struktury INODE), se kterou jsou sdruženy procedury pro práci s místními soubory.

Pro potřeby reprezentace vzdálených souborů, sdílených prostřednictvím protokolu NFS, byl navržen další druh datové struktury: RNODE. Jednotlivé exempláře této datové struktury vznikají pouze na straně klienta, a obsahují mimo jiné i systémové identifikace vzdálených souborů, které si klient vyžádal na příslušném serveru (viz minulý díl). S těmito vzdálenými soubory se pak pracuje prostřednictvím procedur, které jsou s datovými strukturami sdruženy - a právě tyto procedury implementují vlastní protokol NFS pro sdílení vzdálených souborů v sítích. Přesný způsob fungování těchto konkrétních procedur je ovšem natolik zajímavý, že se mu budeme podrobněji věnovat v samostatném dílu tohoto seriálu.

Obr. 77.3.: Představa zpracování požadavku na přístup k souboru

Prozatím si pouze naznačme, jakým způsobem jsou tyto procedury aktivovány. Na straně klienta je prvotním iniciátorem systémové volání, generované aplikační úlohou. Toto volání specifikuje určitou strukturu VNODE, která se zase odkazuje na některou strukturu INODE či RNODE (nebo jiný druh datové struktury, vytvořené pro potřeby konkrétní implementace jiného druhu souborů a adresářů). Podle toho, kam ukazatel v rámci struktury VNODE ukazuje, je pak možné určit konkrétní procedury, které mají být zavolány - viz obrázek 77.3. Výsledkem spuštění procedur, sdružených s datovou strukturou INODE, je pak formulování konkrétního požadavku na server a jeho odeslání.

Obr. 77.4.: Rozhraní VFS/VNODE, INODE a RNODE na straně klienta i serveru

Na straně serveru je příjemcem tohoto požadavku systémový proces (tzv. NFS démon). Ten pak na základě přijatého požadavku generuje systémové volání, které opět specifikuje určitý uzel VNODE. Ten ukazuje na konkrétní datovou strukturu, reprezentující požadovaný soubor či adresář (celou situaci názorně ilustruje obrázek 77.4). V této souvislosti je vhodné si zdůraznit, že tentokráte již musí jít o místní soubor či adresář (a nikoli vzdálený). Tvůrci protokolu NFS totiž vcelku rozumně zakázali tranzitivnost sdílení souborů v sítí. Tedy takovou situaci, kdy server nabízí svým klientům soubory, které sám získává v roli klienta od jiného serveru. Ačkoli by to bylo principiálně možné, není to efektivní. Místo přes prostředníka se totiž každý klient může obrátit přímo na ten server, který požadované soubory skutečně vlastní (jako lokální).

BSD Unix vs. AT&T Unix

Rozhraní VFS/VNODE, které jsme si až dosud popisovali, bylo vytvořeno v rámci tzv. BSD větve Unixu verze 4.2 (viz 75. díl seriálu), kde se také protokol NFS prosadil nejdříve. V druhé hlavní větvi, tzv. AT&T Unixu, existovalo ve verzi System V Release 3 rozhraní s velmi podobnými datovými strukturami FSS (File System Switch). Bylo vyvinuto pro potřeby protokolu RFS (Remote File Sharing) firmy AT&T, který má stejné poslání jako protokol NFS - tedy zajišťovat transparentní sdílení souborů v sítích (ovšem na rozdíl od bezestavového protokolu NFS funguje jako stavový). Protokol NFS se však ukázal být životaschopnějším, a jeho používání se posléze prosadilo i do AT&T Unixu. Spolu s ním pak i rozhraní VFS/VNODE, které se stalo standardní součástí AT&T Unixu od verze System V Release 4.

---