Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (76):

NFS II.

Nejprve si ale znovu p°ipome≥me dalÜφ v²znamnou charakteristiku protokolu NFS, kterß jeho tv∙rc∙m le₧ela velmi na srdci - a to mo₧nost implementovat tento protokol na r∙zn²ch platformßch, v prost°edφ nejr∙zn∞jÜφch operaΦnφch systΘm∙. Bezestavov² charakter protokolu NFS tomuto po₧adavku vychßzφ vst°φc mj. tφm, ₧e zcela zßm∞rn∞ klade minimßlnφ nßroky na schopnosti a spolehlivost p°enosov²ch protokol∙, a dokß₧e vystaΦit prakticky s jak²mkoli p°enosov²m protokolem, kter² je k dispozici.

Po₧adavek na snadnou implementaci v r∙zn²ch prost°edφch, resp. na r∙zn²ch platformßch, se ovÜem net²kß jen klient∙, ale samoz°ejm∞ takΘ server∙. Dnes je vcelku b∞₧nΘ, ₧e v roli file server∙ systΘmu NFS vystupujφ takΘ r∙znΘ ne-UnixovskΘ poΦφtaΦe. Nap°φklad st°ediskovΘ poΦφtaΦe IBM s operaΦnφm systΘmem VM mohou b²t vybaveny protokoly TCP/IP vΦetn∞ NFS, a stejn∞ tak m∙₧e v roli NFS serveru vystupovat nap°φklad i server systΘmu Novell NetWare - k tomu staΦφ zakoupit a nainstalovat na NetWare serveru dopl≥kov² program, tzv. NetWare NFS. Ten sice nenφ zdaleka zadarmo, ale pokud lze v∞°it reklamnφm slogan∙m firmy Novell, vyjde toto °eÜenφ lacin∞ji, ne₧ tradiΦnφ Unixovsk² poΦφtaΦ v roli NFS serveru.

Jestli₧e tedy protokol NFS m∙₧e b²t implementovßn v prost°edφ r∙zn²ch operaΦnφch systΘm∙, pak se nutn∞ musφ n∞jak²m zp∙sobem vyrovnat s jejich odliÜnostmi. O tom, jakß m∙₧e b²t povaha t∞chto odliÜnostφ, jsme si ji₧ n∞co naznaΦili v 70. dφlu - na p°φkladu odliÜnostφ mezi Unixem a MS DOSem. Tv∙rci protokolu NFS se se vÜemi potencißlnφmi odliÜnostmi rozhodli vyrovnat zajφmav²m zp∙sobem: koncipovali samotn² protokol NFS tak, aby se jej tyto odliÜnosti v∙bec net²kaly (a oÜet°enφ t∞chto odliÜnostφ sv∞°ili jin²m protokol∙m, kterΘ stojφ mimo NFS).

Pouze p°es systΘmovou identifikaci

Bylo by samoz°ejm∞ mo₧nΘ zavΘst n∞jakou jednotnou konvenci (nap°φklad tu, kterou pou₧φvß Unix), a pak zajistit p°φpadn² p°evod z/do konvence, kterou pou₧φvß konkrΘtnφ hostitelsk² operaΦnφ systΘm. Tv∙rci protokolu NFS se vÜak rozhodli pro jinΘ °eÜenφ: pokud klient po₧aduje na serveru n∞jakou akci s urΦit²m souborem, pak mu tento konkrΘtnφ soubor neurΦuje jeho jmΘnem, p°φpadnou p°φponou a p°φstupovou cestou, ale pomocφ jednoznaΦnΘho identifikßtoru, kter² se oznaΦuje jako file handle (Φesky nejspφÜe: systΘmovß identifikace), a je zcela nezßvisl² na jakΘkoli mφstnφ konvenci pro pojmenovßvßnφ soubor∙ a sestavovßnφ p°φstupov²ch cest.

Obr. 76.1: P°edstava systΘmovΘ identifikace

Pro klienta je systΘmovß identifikace posloupnostφ bit∙, kterΘ nijak neinterpretuje - jejich v²znam je pro n∞j irrelevantnφ (klient tedy m∙₧e pova₧ovat systΘmovou identifikaci nap°φklad za celΘ Φφslo bez znamΘnka). Z pohledu serveru se vÜak systΘmovß identifikace (file handle) sklßdß ze t°φ Φßstφ, kterΘ po °ad∞ identifikujφ systΘm soubor∙, konkrΘtnφ soubor a jeho instanci (viz obr. 76.1.).

KonkrΘtnφ hodnotu jednotliv²ch bit∙ systΘmovΘ identifikace samoz°ejm∞ urΦuje server, zatφmco klient tuto identifikaci pouze pou₧φvß, a chßpe ji jako jedin², dßle ned∞liteln² celek. SystΘmovΘ identifikace, jednoznaΦn∞ urΦujφcφ konkrΘtnφ soubory, pak ovÜem musφ klientovi poskytovat server, proto₧e pouze on je dokß₧e vytvo°it. Podφvejme se nynφ na formu, jakou se tak d∞je. Nejprve si ale °ekn∞me, ₧e systΘmovß identifikace (file handle) m∙₧e reprezentovat jak konkrΘtnφ soubor, tak i adresß°.

Nynφ si ji₧ p°edstavme situaci, kdy klient mß k dispozici systΘmovou identifikaci n∞jakΘho konkrΘtnφho adresß°e. Jednou z operacφ, kterou m∙₧e na serveru po₧adovat, je vypsßnφ jmen vÜech soubor∙ (a podadresß°∙) v tomto adresß°i (tj. v tom, od kterΘho ji₧ klient vlastnφ systΘmovou identifikaci). Server mu vrßtφ seznam znakov²ch °et∞zc∙ a r∙zn²ch p°φznak∙, ze kter²ch lze mj. poznat, zda znakov² °et∞zec je jmΘnem souboru Φi jmΘnem podadresß°e. Jestli₧e se pak klient rozhodne pracovat s n∞jak²m konkrΘtnφm souborem v tomto adresß°i, musφ nejprve zφskat jeho systΘmovou identifikaci. To ud∞lß prost°ednictvφm dalÜφ mo₧nΘ operace, kterou si vy₧ßdß na serveru, a kterΘ p°edß jako vstupnφ parametr jednak systΘmovou identifikaci adresß°e, a dßle °et∞zec se jmΘnem souboru, kter² zφskal p°i p°edchßzejφcφm v²pisu obsahu tohoto adresß°e. Stejn∞ bude klient postupovat i v p°φpad∞, kdy bude pot°ebovat systΘmovou identifikaci n∞kterΘho z podadresß°∙ danΘho adresß°e.

Jak tomu ale bude v p°φpad∞, kdy klient pot°ebuje "projφt" Φßstφ adresß°ovΘho stromu, aby se dostal k n∞jakΘmu konkrΘtnφmu souboru? Zde je dobrΘ si znovu explicitn∞ zd∙raznit, ₧e vzhledem ke svΘmu bezestavovΘmu charakteru nem∙₧e mφt protokol NFS ₧ßdnou analogii "aktußlnφho adresß°e", ve kterΘm by se klient mohl nachßzet. Klient vÜak m∙₧e vlastnit systΘmovΘ identifikace jednoho Φi n∞kolika adresß°∙, a mß k dispozici mechanismy, pomocφ kter²ch m∙₧e zφskßvat systΘmovΘ identifikace i jejich podadresß°∙ (Φi naopak nad°azen²ch adresß°∙). Tφmto zp∙sobem se m∙₧e postupn∞ dopracovat a₧ k systΘmovΘ identifikaci adresß°e, ve kterΘm se nachßzφ po₧adovan² soubor, a zφskat takΘ jeho systΘmovou identifikaci. Musφ si ovÜem sßm postupn∞ vybudovat "p°edstavu" p°φsluÜnΘho adresß°ovΘho stromu, proto₧e server mu nabφzφ v₧dy jen pohled na jedno patro (resp. jednu ·rove≥) tohoto stromu.

Kde zaΦφt

Zajφmavou otßzkou je ale to, jak²m zp∙sobem klient zφskß onu prvnφ systΘmovou identifikaci. Zde je dobrΘ si uv∞domit, ₧e server nabφzφ sv²m klient∙m v₧dy celΘ adresß°ovΘ stromy, kterΘ se v UnixovΘ terminologii oznaΦujφ jako souborovΘ systΘmy (file systems). Ka₧d² server v₧dy "zve°ej≥uje" seznam t∞chto souborov²ch systΘm∙ (tzv. je exportuje), a ka₧d² klient si z nich m∙₧e vybrat ty, kterΘ si pomocφ operace mount p°ipojφ ke svΘmu globßlnφmu adresß°ovΘmu stromu (pokud je sßm Unixovsk²m poΦφtaΦem), resp. kterΘ si zp°φstupnφ jako samostatnß logickß za°φzenφ (jde-li nap°. o klienta, kter² pracuje pod operaΦnφm systΘmem MS DOS) - jak jsme si podrobn∞ popisovali v 74. dφlu serißlu.

KonkrΘtnφ postup "p°ipojovßnφ" je takov², ₧e klient si nejprve vybere ze seznamu souborov²ch systΘm∙ exportovan²ch urΦit²m serverem ten, kter² jej zajφmß, a pak tomuto serveru vyÜle po₧adavek na jeho p°ipojenφ (provedenφ operace mount). Polo₧ky seznamu p°itom tvo°φ jmΘna ko°en∙ jednotliv²ch adresß°ov²ch strom∙ (souborov²ch systΘm∙), vΦetn∞ p°φstupov²ch cest k nim. Po₧adavek na p°ipojenφ (mount), kter² klient adresuje serveru, tudφ₧ obsahuje jmΘna vΦetn∞ p°φstupov²ch cest, a nutn∞ tedy musφ pou₧φvat n∞jakou konvenci pro jejich sestavovßnφ. Po₧adavek klienta ovÜem nenφ adresovßn p°φmo tΘ entit∞, kterß implementuje NFS server. Jejφm adresßtem je tzv. mount server (doslova: p°ipojovacφ server), kter² nenφ souΦßstφ NFS, a kter² ji₧ musφ b²t uzp∙soben konkrΘtnφ konvenci pro pojmenovßvßnφ adresß°∙ a sestavovßnφ p°φstupov²ch cest, pou₧φvanΘ v prost°edφ, ve kterΘm je server implementovßn.

Obr. 76.2. SystΘmovΘ identifikace a p°φstupovΘ cesty p°i komunikaci klienta se serverem

Tento mount server je tedy tφm, kdo klientovi poskytne prvnφ systΘmovou identifikaci, se kterou se pak ji₧ klient m∙₧e obracet na NFS server a od n∞j zφskßvat dalÜφ systΘmovΘ identifikace - jak naznaΦuje i obrßzek 76.2.

V tuto chvφli se ale nutn∞ vnucuje otßzka, proΦ je tomu prßv∞ takto? Jakß je logika v tom, ₧e tzv. mount server nenφ souΦßstφ NFS serveru (a zp∙sob jeho Φinnosti nenφ definovßn protokolem NFS)?

D∙vody jsou p°edevÜφm praktickΘ. Slu₧by mount serveru jsou vyu₧φvßny relativn∞ velmi z°φdka (typicky jednorßzov∞ p°i spuÜt∞nφ operaΦnφho systΘmu klienta, kter² si v rßmci svΘho startu p°ipojuje souborovΘ systΘmy serveru). Naopak slu₧by NFS serveru mohou b²t vyu₧φvßny velmi Φasto (p°i vÜech operacφch se vzdßlen²mi soubory). Na implementaci NFS serveru jsou proto kladeny velmi velkΘ nßroky, pokud jde o jeho rychlost, zatφmco v p°φpad∞ mount serveru nenφ jeho rychlost rozhodujφcφ. V prost°edφ Unixu je proto NFS server implementovßn jako souΦßst jßdra (aby mohl b²t co mo₧nß nejrychlejÜφ), zatφmco mount server m∙₧e b²t implementovßn mimo jßdro operaΦnφho systΘmu, na stejnΘ ·rovni, jako b∞₧nΘ aplikaΦnφ ·lohy. TakovΘto programy se ale pφÜφ a hlavn∞ ladφ mnohem snßze, ne₧ systΘmovΘ programy, kterΘ majφ b²t souΦßstφ jßdra.

Mount server ovÜem plnφ i n∞kterΘ dalÜφ ·koly, ne₧ jen p°evßd∞t jmΘna adresß°∙ vΦetn∞ p°φstupov²ch cest na systΘmovΘ identifikace. Je to prßv∞ on, kdo skuteΦn∞ "zve°ej≥uje" jmΘna souborov²ch systΘm∙, exportovan²ch serverem. Mß takΘ za ·kol ov∞°ovat identitu u₧ivatel∙, kte°φ si ze sv²ch poΦφtaΦ∙ v roli klient∙ p°ipojujφ souborovΘ systΘmy, a dßle mß i kontrolovat dodr₧ovßnφ p°φstupov²ch prßv k exportovan²m souborov²m systΘm∙m. Dφky tom, ₧e si pro ka₧dΘho u₧ivatele udr₧uje seznam jeho po₧adavk∙ na p°ipojenφ souborov²ch systΘm∙, je mount server nutn∞ stavov² (na rozdφl od bezestavovΘho NFS serveru). Charakter stavovΘ informace, kterou si mount server udr₧uje, vÜak nenφ kritick² pro sprßvnΘ fungovßnφ NFS serveru i jeho klient∙. Jejφ v²znam je spφÜe pomocn², a vyu₧φvß se nap°φklad k tomu, aby server mohl vΦas varovat vÜechny svΘ klienty o tom, ₧e bylo zahßjeno jeho °ßdnΘ ukonΦenφ (tzv. shutdown).