zpět do archivu článků |
rejstřík |
předchozí díl |
následující díl
Jiří Peterka: Co je čím ... v počítačových sítích (77):
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.
zpět do archivu článků | rejstřík |
předchozí díl |
následující díl
Tento článek může být volně šířen, pokud se tak děje pro studijní účely, na nevýdělečném základě a se zachováním tohoto dovětku. Podrobnosti hledejte zde, resp. na adrese
http://ksi.ms.mff.cuni.cz/~peterka/archiv/copyleft.htm