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 (74):
Transparentnφ sdφlenφ soubor∙
V poslednφch t°ech dφlech jsme se podrobn∞ji zab²vali
dv∞ma protokoly (FTP a TFTP). Ty majφ v rodin∞ protokol∙
TCP/IP na starosti takov² p°enos soubor∙, kter² jsme si
oznaΦili jako netransparentnφ. Nynφ je na °ad∞ transparentnφ
p°φstup k soubor∙m a protokol NFS.
Nejprve si ale znovu zopakujme, v Φem je rozdφl mezi
transparentnφm a netransparentnφm p°φstupem (tak, jak jsme
si je zavedli v 70. dφlu): netransparentnφ p°φstup je
takov², p°i kterΘm pro u₧ivatele existuje principißlnφ
rozdφl mezi mφstnφmi soubory a vzdßlen²mi soubory. U₧ivatel
si musφ b²t v∞dom, ₧e urΦit² soubor nenφ mφstnφ, ale ₧e se
nachßzφ na vzdßlenΘm poΦφtaΦi (navφc musφ v∞d∞t kterΘm),
a kdy₧ s nφm chce pracovat, musφ pro to nejprve n∞co ud∞lat
- zajistit p°enos tohoto souboru ze vzdßlenΘho poΦφtaΦe na
sv∙j poΦφtaΦ.
Naproti tomu v p°φpad∞ transparentnφho p°φstupu pro
u₧ivatele neexistuje ₧ßdn² principißlnφ rozdφl mezi mφstnφmi
a vzdßlen²mi soubory. U₧ivatel (resp. jφm provozovanß
aplikace) si m∙₧e myslet, ₧e vÜechny jemu dostupnΘ soubory
jsou mφstnφ, a jako s takov²mi s nimi takΘ pracuje.
SkuteΦnost, ₧e n∞kterΘ soubory mφstnφ nejsou, je p°ed
u₧ivatelem skryta, stejn∞ tak jako vÜechny mechanismy, kterΘ
pot°ebnou iluzi vytvß°φ, a kterΘ zajiÜ¥ujφ pot°ebnΘ p°enosy
cel²ch soubor∙ Φi jejich Φßstφ mezi mφstnφm a vzdßlen²m
poΦφtaΦem.
Jak vznikß iluze
Principißlnφ zp∙sob, jak²m lze transparentnφ p°φstup ke
vzdßlen²m soubor∙m realizovat, ukazuje obrßzek 74.1.:
 |
Obr. 74.1.: P°edstava p°φstupu ke vzdßlen²m soubor∙m
vychßzφ op∞t z modelu klient/server, ve kterΘm u₧ivatel∙v
poΦφtaΦ vystupuje v postavenφ klienta, a vzdßlen² poΦφtaΦ
v postavenφ serveru (file serveru, kter² jako slu₧bu nabφzφ
sv²m klient∙m uchovßvßnφ soubor∙). Pro u₧ivatele (resp. jφm
provozovanou aplikaci) je ovÜem i tento vztah transparentnφ
- u₧ivatel vznßÜφ veÜkerΘ svΘ po₧adavky na p°φstup
k soubor∙m jednΘ a tΘ₧e entit∞ (slo₧ce operaΦnφho systΘmu,
kterou prozatφm nazveme shell). Ta rozhoduje o tom, zda
po₧adavek je po₧adavkem na p°φstup k takovΘmu souboru, kter²
je lokßlnφ, nebo zda jde o po₧adavek na p°φstup ke
vzdßlenΘmu souboru, a podle toho pak p°φsluÜn² po₧adavek
p°edß k vy°φzenφ bu∩ mφstnφmu systΘmu soubor∙, nebo
programovΘ entit∞, kterß implementuje klienta. Pokud nastal
tento druh² p°φpad, klient zformuluje po₧adavek na p°φstup
ke vzdßlenΘmu souboru do takovΘho tvaru, kter² je
srozumiteln² pro entitu v roli serveru na vzdßlenΘm
poΦφtaΦi, a po₧adavek jφ odeÜle. Server zajistφ vÜe pot°ebnΘ
pro vy°φzenφ po₧adavku (nap°. naΦtenφ souboru, kter² pro n∞j
ji₧ je mφstnφ), a v²sledek odeÜle po sφti zp∞t klientovi.
Ten jej pak vrßtφ zp∞t shellu, a ten zase u₧ivateli.
PraktickΘ napln∞nφ tohoto schΘmatu mß dv∞ relativn∞
samostatnΘ strßnky: tou prvnφ je konkrΘtnφ protokol,
prost°ednictvφm kterΘho komunikuje klient se serverem, a tou
druhou je pln∞ transparentnφ "zaΦlen∞nφ" mechanismu p°φstupu
ke vzdßlen²m soubor∙m do celkovΘho systΘmovΘho prost°edφ na
klientskΘm poΦφtaΦi. Prßv∞ u tΘto druhΘ strßnky se nynφ
zastavφme podrobn∞ji, zatφmco tu prvnφ si ponechßme na dalÜφ
dφly.
Zßle₧φ na operaΦnφm systΘmu
Mßme-li na urΦitΘm poΦφtaΦi implementovat takov²
mechanismus p°φstupu ke vzdßlen²m soubor∙m, kter² mß b²t pro
u₧ivatele pln∞ transparentnφ, pak se nutn∞ musφme
p°izp∙sobit tomu, jakΘ konvence, postupy a mechanismy
pou₧φvß pro p°φstup k soubor∙m operaΦnφ systΘm danΘho
poΦφtaΦe. Mß-li toti₧ u₧ivatel pracovat i se vzdßlen²mi
soubory p°esn∞ stejn²m zp∙sobem, jako se soubory mφstnφmi,
musφ k tomu vyu₧φvat p°esn∞ stejnΘ prost°edky a postupy.
Jestli₧e tedy konkrΘtnφ protokol pro vlastnφ p°enos
soubor∙ mezi uzlov²mi poΦφtaΦi m∙₧e (Φi spφÜe musφ) b²t
stejn², zp∙sob jeho zp°φstupn∞nφ u₧ivatel∙m a jimi
provozovan²m aplikacφm je ji₧ zßvisl² na konkrΘtnφm
poΦφtaΦi, p°esn∞ji na jeho operaΦnφm systΘmu.
Podφvejme se proto, jak vypadß situace v p°φpad∞ dvou
operaΦnφch systΘm∙ - Unixu a MS DOSu.
Unix montuje
 |
Obr. 74.2.: P°edstava operace mount v OS Unix
OperaΦnφ systΘm Unix si organizuje vÜechny svΘ soubory
do jedinΘho adresß°ovΘho stromu. Fyzicky mohou b²t tyto
soubory umφst∞ny na r∙zn²ch za°φzenφch (pevnΘm disku,
disket∞ apod.), a sdru₧eny do tzv. souborov²ch systΘm∙
(filesystems) - nap°φklad obsah diskety m∙₧e tvo°it takov²to
souborov² systΘm, samostatn² oddφl (partition) pevnΘho disku
m∙₧e tvo°it jin² souborov² systΘm apod. Z pohledu u₧ivatele
jsou ale tyto souborovΘ systΘmy sestavovßny do jednoho
jedinΘho adresß°ovΘho stromu, jeho₧ zßklad tvo°φ tzv.
ko°enov² souborov² systΘm (root filesystem). KonkrΘtnφ
mechanismus, kter² toto sestavovßnφ umo₧≥uje, je operace
mount (doslova: p°ipoj, p°imontuj). Z pohledu u₧ivatele
funguje tak, ₧e cel² souborov² systΘm p°ipojφ k zadanΘmu
adresß°i globßlnφho adresß°ovΘho stromu jako jeho nov²
podstrom - viz obrßzek 74.2.
 |
Obr. 74.3.: P°φstup k mφstnφm a vzdßlen²m soubor∙m v Unixu
Kdy₧ se pak u₧ivatel Φi jakßkoli aplikace odkazuje na
n∞kter² soubor z takto "p°imontovanΘho" systΘmu soubor∙, lze
si p°edstavit, ₧e jeho po₧adavek projde od ko°ene a₧ do
mφsta, kde je p°φsluÜn² systΘm soubor∙ p°ipojen, a odsud je
pak p°edßn ovladaΦi p°ipojenΘho systΘmu soubor∙, kter² tento
po₧adavek ji₧ dokß₧e vy°φdit - viz obr. 74.3.
Takto fungujφcφ prost°edφ vychßzφ vst°φc pln∞
transparentnφmu p°φstupu ke vzdßlen²m soubor∙m, a umo₧≥uje
realizovat jej velmi p°irozen²m zp∙sobem. StaΦφ rozÜφ°it
schopnosti operace mount tak, aby umo₧≥ovala p°ipojit
i takovΘ systΘmy soubor∙ Φi jejich Φßsti, kterΘ se fyzicky
nachßzφ na vzdßlenΘm poΦφtaΦi, a dßle zajistit, aby veÜkerΘ
po₧adavky na p°φstup k t∞mto soubor∙m se na danΘm poΦφtaΦi
dostaly k entit∞, kterß implementuje klienta - viz obr.
74.3. Ta pak ji₧ zajistφ vÜe pot°ebnΘ.
DOS trvß na logick²ch jednotkßch
Jestli₧e operaΦnφ systΘm Unix sestavuje vÜechny systΘmy
soubor∙ v₧dy jen do jedinΘho stromu, kter² pak nepot°ebuje
nijak pojmenovßvat, operaΦnφ systΘm MS DOS se na svΘ
adresß°e a v nich obsa₧enΘ soubory dφvß pon∞kud jin²m
pohledem. To, co Unix sestavuje pomocφ operace mount do
jedinΘho celku, ponechßvß MS DOS odd∞lenΘ - obsah diskety
v ka₧dΘ z disketov²ch mechanik chßpe jako samostatn² celek,
a stejn∞ tak ka₧d² oddφl (partition) pevnΘho disku Φi tzv.
RAMdisk. Ka₧d² takov²to celek (v terminologii DOS-u naz²van²
drive, a p°edstavujφcφ logickou diskovou jednotku) musφ b²t
jednoznaΦn∞ identifikovateln², a tak mu DOS p°i°azuje
jednopφsmennΘ oznaΦenφ: nap°φklad drive A: je prvnφ
disketovß jednotka, B: p°φpadnß druhß disketovß jednotka, C:
prvnφ oddφl (partition) prvnφho pevnΘho disku. Navφc nemß MS
DOS ₧ßdnou obdobu UnixovskΘ operace mount (a ani ji
nepot°ebuje).
 |
Obr. 74.4.: Pohled na vzdßlenΘ soubory v prost°edφ MS DOSu
V prost°edφ MS DOSu proto musφ b²t pln∞ transparentnφ
p°φstup ke vzdßlen²m soubor∙m implementovßn tak, aby systΘmy
soubor∙ vzdßlenΘho poΦφtaΦe Φi jejich podstromy vystupovaly
jako samostatnΘ celky (logickΘ jednotky, drives) - viz obr.
74.4.
DalÜφm nedostatkem MS DOSu je, ₧e nedokß₧e v₧dy
pot°ebn²m zp∙sobem rozeznßvat po₧adavky na p°φstup ke
vzdßlen²m soubor∙ a p°edßvat je tomu, kdo je dokß₧e vy°φdit.
Proto je obvykle t°eba tyto po₧adavky p°esm∞rovßvat jeÜt∞
d°φve, ne₧ se dostanou k MS DOSu - vrstvou, kterß "p°ekryje"
DOS, zachytßvß vÜechny po₧adavky na p°φstup k soubor∙m, ty
"mφstnφ" p°edßvß DOSu, a pro ostatnφ pak ve spoluprßci
s dalÜφmi entitami (implementujφcφmi klienta) za°izuje vÜe
pot°ebnΘ. No a prßv∞ touto p°ekr²vajφcφ vrstvou je entita,
kterou jsme si d°φve oznaΦili jako shell (co₧ v doslovnΘm
p°ekladu znamenß plßÜ¥). V prost°edφ MS DOSu, kter²
nepodporuje multitasking, musφ mφt tato entita formu
rezidentnφho programu.
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://archiv.czech.net/copyleft.htm
