DIPLOMOV` PR`CE - cuni.cz

Universita Karlova v PrazeMatematicko-fyzikální fakulta

DIPLOMOVÁ PRÁCE

Petr Kulhavý

Komparativní analýza síťových souborových systémů

Katedra softwarového inženýrství MFF UK

Vedoucí diplomové práce: Mgr. David Bednárek

Studijní program: Informatika

Poděkování

Na tomto místě bych chtěl poděkovat lidem, bez jejichž pomoci by nikdy tato prácenevznikla. Mé díky patří zejména Mgr. Davidu Bednárkovi za vedení diplomové práce,mým rodičům za jejich trpělivost, morální i materiální podporu a neustálé popohánění,Ing. Janu F. Chadimovi za konsultace a laskavé zapůjčení hardware pro testování a RNDr.Petru Stupkovi a Pracovišti počítačové techniky Právnické fakulty University Karlovy zaposkytnutí prostředí k měření výkonu souborového systému Novell.

Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitímcitovaných pramenů. Souhlasím se zapůjčováním práce.

V Praze dne 18.dubna 2003 Petr Kulhavý

Obsah

1. Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1 Pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Síťové souborové systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Architektura síťových souborových systémů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Remote procedure call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Přenosové protokoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Vlastnosti souborového systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Dostupnost a přenositelnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Vlastnosti z klientského hlediska . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 Bezpečnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5 Vlastnosti serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Měření vlastností souborových systémů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Vytyčení cílů měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Generátory zátěže . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.3 Find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.4 Tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.5 Iozone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.6 Blkread a blkwrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Sledované veličiny a měřící nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Chrono, měření času . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.2 Shepherd, měření síťové zátěže . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.3 Iozone, měření propustnosti souborového systému . . . . . . . . . . . . . . 23

3.3.4 NistNet, emulace sítě WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Hardware a software testovacího prostředí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5 Průběh testů a měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 Problémy s měřením . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6.1 Testování systému Novell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6.2 Ovlivnění výsledků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Network File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Síťová architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

– 1 –

4.3.1 Sun RPC a XDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Bezestavovost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Model souborového systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1 Zamykání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4.2 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 Zabezpečení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.1 Autentizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.2 Mapování uživatelů a skupin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5.3 Bezpečnostní problémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5. Self Certifying File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.1 Součásti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.2 Jmenný prostor a sémantika operací . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.3 Bezpečnost a komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.4 Bezpečnostní rizika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6. NFS4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 Úvod a historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Rozdíly od předchozích verzí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2.1 Rozdíly v sémantice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2.2 Model souborového systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.3 Skládání RPC požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.4 File–handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.5 Delegace operací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.6 Zamykání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.7 Atributy objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3 Bezpečnostní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Replikace a migrace dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7. SMB/CIFS, Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1 Úvod a historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2 Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2.1 Řetězení zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.2.2 Další služby protokolu SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.3 Model souborového systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.3.1 Adresace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.3.2 Jmenný prostor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.3.3 Souborový systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

– 2 –

7.3.4 Zámky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.3.5 Transakce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.4 Bezpečnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4.1 Autentizace uživatelů a zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4.2 Bezpečnostní modely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8. Andrew File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.1 Úvod a historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.1.1 Cíle AFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.2.1 Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.2.2 Buňky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.2.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.2.4 Jmenný prostor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3 Bezpečnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3.1 Bezpečnostní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3.2 Autentizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3.3 Autorizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.4 Klient, datová cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.4.1 Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.4.2 Odlišnosti v sémantice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

9. Novell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9.1 Úvod a historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9.3 Souborový systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

10. Výsledky měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.1 Měření v běžných podmínkách . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.2 Chování za nepříznivých podmínek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10.3 Režie protokolů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

11. Srovnání souborových systémů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

12. Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

13. Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A. Dodatek: Obsah CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

– 3 –

Název práce: Komparativní analýza síťových souborových systémůAutor: Petr KulhavýKatedra: Katedra softwarového inženýrstvíVedoucí diplomové práce: Mgr. David BednárekE-mail vedoucího: [email protected]: Díky velkému rozvoji počítačových sítí za několik posledních let došlo též kezvýšení nároků na síťové souborové systémy. Tato práce se snaží srovnat široce rozšířenésouborové systémy po teoretické i praktické stránce.

Při zatížení reálnými i syntetickými generátory zátěže jsou zkoumány souborové sys-témy AFS, NFS, NFS4, SFS, SMB/CIFS a Novell. Srovnání probíhá v prostředí společnéplatformy klientů na operačním systému Linux, servery jsou vybírány z různých platforem.Reálné generátory se snaží simulovat typické podmínky při práci se soubory v UNIXovémprostředí, syntetické mají za úkol změřit skutečnou propustnost, dobu trvání a zatížení sítěběhem jednotlivých operací. Měření probíhají na lokální síti, zkoumány jsou též vlastnostia chování protokolů v nepříznivých podmínkách pomalých a chybových linek.

Na teoretickém poli je rozebírána architektura zkoumaných systémů, zajímavé vlast-nosti a myšlenky jednotlivých návrhů. Výsledkem práce je podtržení význačných vlastností,pojmenování nedostatků a srovnání rychlosti, náročnosti a využitelnosti jednotlivých sys-témů v rozličných podmínkách.Klíčová slova: AFS, NFS, NFS4, SFS, Samba, SMB, CIFS, Novell, síťový souborovýsystém, UNIXový klient, srovnání, výkon

Title: Comparative Analysis of Network FilesystemsAuthor: Petr KulhavýDepartment: Department of Software EngineeringSupervisor: Mgr. David BednárekSupervisor’s e-mail address: [email protected]: Due to a huge evolution of computer networks during last several years require-ments of network filesystems grew up. This thesis tries to compare widespread networkfilesystems in theoretical and practical scope.

Filesystems AFS, NFS, NFS4, SFS, SMB/CIFS and Novell are examined in stressconditions of real and synthetic load generators. Filesystem clients are compared oncommon platform of operating system Linux, servers are running on different platforms.Real load generators try to simulate typical conditions of user’s work with files in UNIXenvironment. Synthetic generators try to measure real performance, operation runningtime and network load during individual operations. Measurements take place on localnetwork, behavior in indisposed conditions of slow and lossy lines is examined too.

From theoretical and design view this work analyses architecture, ideas and features ofthe filesystems. This work tries to point out qualities and minuses of examined filesystems,compare performance, requirements and usability of the systems in various conditions.Keywords: AFS, NFS, NFS4, SFS, Samba, SMB, CIFS, Novell, UNIX client, networkfile system, comparison, performance

– 4 –

1. ÚvodZa několik posledních let došlo k obrovskému rozvoji počítačových sítí, ať už v nárůstu

rychlosti nebo rozšířenosti mezi uživatele. Dnes prakticky každý počítač má možnost býtzapojen do celosvětové sítě Internet. S rozmachem počítačových sítí rapidně vzrostlapotřeba komunikace, sdílení dat a využití síťových souborových systémů.

Síťových souborových systémů bylo navrženo mnoho, některé dávno v historii, kdyvývoj počítačových sítí teprve začínal, některé před několika málo lety. Rovněž rozšířenostsíťových souborových systémů se liší, některé se dostaly do obecného užívání, jiné sepoužívají pouze pro specifické účely, další dávno upadly v zapomnění.

Se zvyšujícím se výkonem počítačů, rostoucí velikostí dat, kapacitou diskových médiía přenosovou rychlostí počítačových sítí podstatně rostou i nároky kladené na síťovésouborové systémy. Jedná se zejména o požadavky na rychlost, zatížení, multiplatformnípřenositelnost, ale také o nároky na bezpečnost.

Tato práce si bere za cíl porovnat široce používané a rozšířené síťové souborové sys-témy. Porovnání nebude probíhat jen na poli teoretickém a principiálním, ale také v prak-tickém nasazení, kde bude sledován výkon, multiplatformní rozšířenost a další praktickévlastosti důležité pro každodenní práci uživatele. V teoretické části se zaměříme zejménana obecné principy a mechanismy systémů a v praktické části pak bude rozebíráno chováníkonkrétních implementací z pohledu aplikace běžící na klientu.

U většiny vybraných systémů existuje mnoho implementací klientů i serverů pro různéplatformy. Aby bylo možno souborové systémy spravedlivě porovnat, bylo nutno všechnyklienty umístit do rovnoprávného postavení, tedy na stejnou platformu. K tomu účelubyla vybrána platforma UNIX, která nabízí větší dostupnost, relevantnost testů a lepšímožnosti měření různých systémových parametrů nežli platforma Windows.

Z výše uvedených důvodů byly k porovnání vybrány souborové systémy, pro něžexistuje volně dostupný klient na platformě UNIX. Jak bylo zjištěno, nejvíce dostupnýchklientů existuje pro operační systém Linux, z toho důvodu byly klienty porovnáványna této platformě. Servery byly vybírány nejen ze světa UNIXu, ale i ze světa Windows.Střed zájmu práce je směrován na souborové systémy AFS, NFS, NFS4, SFS, SMB/CIFSa Novell.

Některé systémy nezahrnují pouze práci se vzdálenými soubory, ale i další služby jakonapříklad sdílení tiskáren, vzdálené vykonávání příkazů, vzdálenou konfiguraci a správusystému a další. Cílem práce není hodnotit takovéto služby, ale pouze tu část týkající sesouborového systému.

Pro testování byly vybrány jak reálné, tak syntetické generátory provozu. Při jejichspouštění byly sledovány různé systémové parametry běhu jako síťová zátěž, zátěž pro-cesoru, doba trvání a zpoždění prováděných operací, propustnost jednotlivých operacív kilobytech za sekundu. Dále byly sledovány schopnosti souborových systémů efektivněvyužít dané hardwarové prostředky.

Práce začíná souhrnným pohledem na síťové souborové systémy, označením problémů,s nimiž se souborové systémy potýkají, a důležitých aspektů návrhů jednotlivých systémů.

– 5 –

V další kapitole, která se zaměřuje na zkoumání praktické stránky souborových systémů,jsou podrobně rozebrány cíle měření, sledované veličiny, měřící nástroje a způsob zpraco-vání výsledků a popsány metody, kterými byly tyto aspekty měřeny. Následují kapitolypopisující jednotlivé souborové systémy a jejich významné rysy, klady a nedostatky. De-sátá kapitola obsahuje výsledky testů a poznatky z jednotlivých měření. Poslední kapi-tola porovnává jednotlivé souborové systémy a shrnuje rozdíly mezi nimi. Následuje závěrpráce a seznam literatury.

K práci je též přiloženo CD s testovacími programy, jejich vstupními daty, zdrojovýmikódy testovaných verzí souborových systémů, veškerými protokoly, grafy a výsledky testů.Obsah CD lze nalézt v dodatku.

1.1 Pojmy

Klient, server, model peer–to–peer. Komunikace mezi počítači může probíhatdvěma různými způsoby. Buďto si jsou obě komunikující strany rovnocenné a nelze roz-lišit, která ze stran logicky nabízí nějaké služby a která tyto služby využívá, v takovémpřípadě se jedná o tzv. peer–to–peer komunikaci. Nebo lze stroje striktně logicky a funk-cionálně rozdělit na počítač poskytující své prostředky a služby, který se označuje jakoserver, a počítač tyto služby a prostředky využívající, který je označován jako klient. V ar-chitektuře klient–server se typicky programové vybavení klientu a serveru podstatně liší.Systémy typu peer–to–peer jsou obecně vhodnější pro menší počet propojených počítačůa většinou jsou lépe i administrovatelné. V této symetrické architektuře stačí propojitlibovolné dva počítače a ty již mohou spolu komunikovat bez nutnosti většího zásahu dokonfigurace. Výhodou asymetrického modelu klient–server je možnost vytvoření robust-ního řešení, které je schopno například rozdělovat zátěž mezi servery, replikovat, migrovata zálohovat data.

Souborový systém. Data na počítačích jsou na permanentních médiích, jakými jsounapříklad pevné disky, disky CD-ROM a další, ukládána v jisté dobře definované struk-tuře. Z programátorského a aplikačního hlediska však není důležitá konkrétní strukturarozmístění dat na médiu, neboť programátor ani aplikace většinou k datům na pevnémdisku nemá přímý přístup, ale je důležitá množina funkcí aplikačního rozhraní, pomocíkterých se s daty pracuje. Toto API společně se strukturou na pevném médiu budemenazývat souborovým systémem, anglicky filesystem. Jedná-li se o souborový systém nadisku počítače, mluvíme o lokálním souborovém systému.

Síťový souborový systém. V této práci se však lokálními souborovými systémynebudeme zabývat, ale bude nás zajímat vzdálená práce se souborovým systémem. Ne-budeme se tedy zajímat pouze o způsob ukládání dat na serveru a o API, pomocí kteréhose k datům přistupuje, ale zaměříme se zejména na způsob komunikace mezi klientema serverem a na API, které server vzdáleně nabízí klientu. Souhrnně tedy pod pojmemsíťový souborový systém budeme označovat aplikační komunikační protokol mezi klien-tem a serverem, API, které server nabízí klientu pro práci se serverem, API, které klientnabízí uživatelské aplikaci běžící na klientu, a konečně formát uložení dat na lokálnímdisku serveru.

Hostitelský souborový systém. Pokud síťový souborový systém nepopisuje, jakým

– 6 –

způsobem budou data ukládána na disku serveru, ale jen definuje komunikační protokola příslušná API, serverův lokální souborový systém, na kterém jsou data uložena, budemeoznačovat jako hostitelský souborový systém.

Hostitelský operační systém. Pokud budeme v souvislosti s klientem nebo ser-verem hovořit o operačním systému, který běží na klientu nebo serveru, budeme tentonazývat hostitelským operačním systémem.

Soubor. Samotná data na souborovém systému jsou organisována do logických jed-notek nazývaných soubory. Soubor krom uložených dat obsahuje ještě přídavné informacejako jméno, vlastníka souboru, přístupová práva, informace o času vytvoření a času po-slední modifikace.

Adresář, adresářová struktura, kořenový adresář, položka adresáře. Sou-bory v souborovém systému jsou z důvodu intuitivnějšího dohledání uživatelem zařazenydo hierarchické struktury grafově ekvivalentní stromu nebo souvislému orientovanémuacyklickému grafu, která se nazývá adresářová struktura. Uzly grafu této struktury senazývají adresáře a kořen grafu, respektive vrchol se vstupním stupněm nula, se nazývákořenový adresář. Adresáře mohou obsahovat soubory nebo další podadresáře. Jednotlivéobjekty obsažené v adresáři se nazývají položky adresáře. Každý adresář je podobně jakosoubor označen jménem, vlastníkem, časem vytvoření, přístupovými právy a případnědalšími informacemi.

Speciální soubor. Některé operační systémy na svých souborových systémech umož-ňují soubory užívat krom k ukládání dat také k jiným účelům, například jako komuni-kační bod mezi aplikacemi a jádrem operačního systému, jako komunikační body meziaplikacemi navzájem a podobně. Souborům, které nenesou data a které slouží k těmtospeciálním účelům, se říká speciální soubory. Pokud souborový systém poskytuje speciálnísoubory, mluvíme pak z důvodu zvýraznění o souborech nesoucích data jako o regulárníchnebo běžných souborech.

Objekt souborového systému, objekt. Adresáře, soubory a speciální soubory sesouhrnně nazývají objekty souborového systému, zkráceně objekty.

Cesta, komponenty cesty. Jméno objektu je v rámci adresáře, ve kterém se objektnachází, jednoznačné. Každý objekt lze tedy v rámci souborového systému identifikovatposloupností jmen adresářů na orientované cestě z kořene adresářové struktury k ad-resáři, ve kterém je objekt obsažen. Pokud na konec této posloupnosti přidáme jménoobjektu, dostáváme cestu k objektu. Jednotlivé prvky posloupnosti se nazývají kompo-nenty adresářové cesty. Různé souborové systémy se krom způsobu uložení a práce sesoubory liší též způsobem oddělování jednotlivých komponent adresářových cest a názvysouborů. Jestliže je adresářová struktura grafově ekvivalentní stromu, identifikuje cestaobjekt jednoznačně v rámci celého souborového systému.

Jmenný prostor. Každý souborový systém dovoluje pojmenovávat objekty, kteréjsou na něm umístěné, jiným způsobem. Názvy objektů a cesty k objektům na konkrétnímsouborovém systému lze popsat určitou, pro souborový systém pevně danou, gramatikou.Jazyk generovaný touto gramatikou budeme nazývat jmenným prostorem.

– 7 –

ACL. Přístup k objektům souborového systému může být kontrolován různými způ-soby, v nejjednodušším případě je u každého objektu uložena bitová maska jednotlivýchpráv pro uživatele, skupinu a ostatní. Pokročilejší způsob nazývaný ACL (Access ControlList) umožňuje jemnější nastavení přístupových práv, u každého objektu je uložen seznamobsahující dvojice (principal, práva), kde principal je uživatel nebo skupina uživatelů, nadruhém místě ve dvojici je množina přístupových práv k objektu.

Daemon. Operační systém nevykonává všechnu práci v jádře, ale některé části běžív uživatelském režimu, který s jádrem komunikuje. Daemon je systémový program běžícív uživatelském módu operačního systému, který zajišťuje nějakou systémovou službu jakonapříklad tisk. Síťové souborové systémy často používají ke svému provozu své vlastnídaemony.

– 8 –

2. Síťové souborové systémyV této kapitole vysvětlíme obecnou architekturu síťových souborových systémů a po-

píšeme některé důležité vlastnosti.

Během vývoje souborových systémů bylo z praktických měření zjištěno několik důle-žitých faktů práce aplikací se soubory, jak uvádějí studie [84][85][86]. Z těchto poznatkůvychází většina návrhů síťových souborových systémů.

Uvedené studie ukazují, že většina souborů, s nimiž je na souborovém systému praco-váno, je velmi malá — velikost 80% souborů nepřesahuje cca 30kB. Aplikace typicky vícečtou než zapisují a z přístupů k souborům převažuje sekvenční nad náhodným, 60% pří-stupů je sekvenčních. Dále mnoho souborů má pouze dočasný ráz, jejich krátký životnícyklus začíná vytvořením, následují zápisy a čtení a život končí smazáním. Typickýmpříkladem použití dočasných souborů může být kompilace, ukládání krátkodobých me-zivýsledků při různých transformacích dat, grafických transformacích a další. 55% nověvytvořených souborů je do 5 sekund smazáno a 26% nově vytvořených souborů je do4 milisekund přepsáno.

Velká část souborů, které nejsou dočasné, je za svůj život zapsána pouze jednou a pakjen čtena, těmito soubory jsou například binární soubory aplikací, které jsou typickyvytvořeny během instalace systému a pak po velmi dlouhou dobu (řádově měsíce a déle)nejsou modifikovány a jsou pouze čteny.

Procesy při práci se souborovým systémem mají otevřeno naráz jen velmi málo sou-borů, jejich počet se pohybuje v řádu jednotek. Velké množství souborů je otevřeno pouzena krátkou dobu. Doba otevření u 80% souborů nepřekročí 1 sekundu.

Sdílení souborů pro zápis se mezi procesy příliš často nevyskytuje, soubory jsou sdí-leny většinou pouze pro čtení. V praxi mohou být sdíleny kupříkladu systémové knihovnynebo binární kódy aplikací. Sdílení pro zápis provádějí většinou jen specialisované aplikacejako například databáze.

2.1 Architektura síťových souborových systémů

Architekturu síťového souborového systému lze zkoumat z několika pohledů. Jednímz pohledů může být architektura klientu nebo serveru, jiný pohled rozebírá architekturucelkovou, zda se jedná o model peer–to–peer, nebo o model klient–server.

Všechny souborové systémy na operačním systému Linux jsou zastřešeny vrstvouvirtuálního souborového systému VFS. Tato vrstva nabízí jednotné rozhraní systémo-vých volání pro všechny souborové systémy bez ohledu na to, zda se jedná o lokální,nebo o vzdálené souborové systémy. Pod VFS sídlí jednotlivé souborové systémy jakonapříklad EXT2, NTFS, NFS, ReiserFS atd. Systémová volání procházejí vrstvou VFS,která rozhodne, o který souborový systém se jedná, a předá volání podvrstvě obsluhujícídaný souborový systém. Obrázek 3 ilustruje zapojení souborového systémů NFS do roz-hraní VFS. Ne všechy souborové systémy si vystačí s UNIXovými syscally souborovéhosystému, proto případné další speciální funkce konkrétního souborového systému jsouimplementovány pomocí volání ioctl().

– 9 –

Požadavky aplikace jsou operačním systémem předány klientu souborového systému,který může běžet v uživatelském režimu jako daemon, nebo v jádře operačního systému.

Každá implementace má své výhody a nevýhody. Klient nebo server implementovanýv kernelu je rychlejší, ale přináší podstatně větší riziko pro systém v případu havárie neboprolomení bezpečnosti. Dojde-li k takové fatální události, je ohrožen celý operační systém.Běží-li klient nebo server jako daemon v uživatelském módu, v případě havárie přestaneběžet pouze příslušná služba a zbytek systému není ohrožen. Parametry, které předáváaplikace daemonu, však musí být přenášeny přes jádro, což zpomaluje operace soubo-rového systému. Operační systém může též dovolovat mapování stránek mezi procesyv uživatelském režimu (příkladem může být Linux) a daemon může přímo mapovat dataz aplikace bez toho, aby data byla kopírována přes kernel. To však v případě prolomeníbezpečnosti daemonu může též vést k závažným bezpečnostním problémům.

Při implementaci klientu v uživatelském módu potenciálně hrozí nebezpečí deadlocku,pokud dojde k vyswapování daemonu. Není-li daemon v operační paměti a paměť jezaplněna požadavky na zápis do příslušného souborového systému, dojde k deadlocku,protože kernel k zavedení daemonu do operační paměti potřebuje uvolnit nějaké stránky(za předpokladu, že stránky s daty, které je nutno uložit na filesystem, nejsou odkládánydo swapu) a k jejichž uvolnění ovšem potřebuje daemon, čímž vzniká cyklická závislosta deadlock. Proto je nutné, aby daemon nebyl nikdy vyswapován, nebo aby cache soubo-rového systému nikdy neobsadila celou paměť. Jinou možností by bylo používat lokálnídisk jako cache, čímž by bylo zaručeno, že vždy bude možno data odložit na disk a tímuvolnit paměť. Druhý zmiňovaný přístup je použit v síťovém souborovém systému CODA,který však nebyl v rámci této práce zkoumán.

2.1.1 Remote procedure call

Klient komunikuje se serverem formou výměny zpráv po síti. Klient typicky odesílápožadavky na server a server vrací odpovědi. V některých souborových systémech (na-příklad v NFS4) server vysílá též požadavky, na které klient odpovídá, komunikace je takoboustranná.

Většina síťových souborových systémů komunikuje pomocí mechanismu vzdálenéhovolání funkcí RPC (Remote Procedure Call). Tento mechanismus, který se velmi často po-užívá při programování distribuovaných aplikací, umožňuje vykonávat programové funkcev jiném adresním prostoru, jako by byly umístěny v adresním prostoru stejném. Volanáfunkce a volající program jsou typicky uloženy na různých počítačích. Existuje několikprotokolů implementujících vzdálené volání funkcí [5][6][7][47]. Funkce mohou být vzdá-leně volány synchronně i asynchronně, záleží na konkrétním protokolu.

Komunikující strany obecně mohou sídlit na různých hardwarových architekturácha jejich representace dat v paměti může být nekompatibilní, z toho důvodu musí protokolvzdáleného volání funkcí též unifikovat formát předávaných dat nezávisle na hardwarovéarchitektuře. Kompatibilita dat musí být zajištěna v následujících bodech:

� byte order — na různých architekturách je nejvýznamnější byte v integeru uloženna různých pozicích

– 10 –

� zarovnání — hodnoty s lichým počtem bytů mohou být zarovnány zleva nebozprava

� union — různé kompilátory mohou konstrukci union ukládat v paměti různě

� floating point — existuje mnoho representací čísel v pohyblivé desetinné čárce

� pole a řetězce — jak přenášet objekty s proměnlivou délkou jako jsou polea řetězce

Obecně je protokol vzdáleného volání funkcí implementován pomocí speciálního roz-hraní umístěného na obou komunikujících stranách, které odstiňuje síťovou komunikaci,zajišťuje překlad dat a obaluje volání funkcí, na cílové straně pak data rozbaluje, volápříslušnou funkci a stejným způsobem vrací návratovou hodnotu.

RPC procedury jsou rozděleny na klientskou a serverovou část. Část, která se volá naklientské straně, pouze převezme parametry, uloží je do síťové zprávy, přidá identifikaciprocedury, a pošle zprávu serveru. Serverová část dekóduje argumenty, vykoná vlastníkód funkce, uloží návratovou hodnotu do síťové zprávy, kterou odešle zpět klientu. Klientdekóduje návratovou hodnotu a vrátí se zpět do programu. Z pohledu klientu vypadávolání funkce stejně jako volání kterékoliv lokální funkce. Život serveru je velice jedno-duchý: po spuštění zaregistruje všechny funkce, které poskytuje, a vstoupí do nekonečnéčekací smyčky. Když přijde požadavek vzdáleného volání funkce, zavolá se příslušná za-registrovaná funkce a po vykonání se server vrátí zpět do čekací smyčky.

Klientvolajícíprocedura

Klient stubsíťovýpřenos

Server stubsíťovýpřenos

Servervolaná

procedura

argumenty

návratová hodnota návratová hodnota

zprávys požadavkem

zprávys požadavkem

zprávys odpovědí

zprávys odpovědí

argumenty

Obr. 1: Architektura RPC aplikace.

Na program využívající RPC můžeme pohlédnout i z hlediska rozdělení služeb meziaplikační kód a ostatní RPC komponenty implementující vzdálené volání. Z tohoto po-hledu můžeme aplikaci rozdělit na tři disjunktní části, tzv. RPC runtime, klient a serverstub a aplikační kód, jak ukazuje obrázek 1.

Jádrem modelu vzdáleného volání procedur je RPC runtime, což je knihovna funkcía služeb zajišťujících síťovou komunikaci. V průběhu vzdáleného volání klientský a serve-rový RPC runtime zajišťuje navazování spojení, výměnu dat mezi oběma stranami a ošet-

– 11 –

řování případných chyb komunikace. Rozhraní k RPC runtime tvoří RPC API, které téžumožňuje přístup k jmenným a bezpečnostním službám, které vrstva RPC runtime kesvému běhu využívá.

Stub je část aplikačního kódu, která není generována programátorem aplikace, aleautomaticky během překladu. Stub nejprve programátor popíše ve speciálním jazyce IDL(Interface Definition Language) a pak vygeneruje IDL překladačem, který z jazyka IDLvytvoří zdrojové texty například jazyka C. Tato vrstva má za úkol odstínit síťový pře-nos od vlastního kódu aplikace. Vrstva se rozděluje na klientský stub a serverový stub,pro každou stranu je vygenerován jiný kód, na klientské straně má stub za úkol získatparametry procedury, převést je do podoby, kterou vyžaduje RPC runtime vrstva, a s vy-užitím RPC runtime přenést data společně s kódem procedury směrem k serveru. Popřijetí odpovědi má za úkol zpět dekódovat návratovou hodnotu a předat ji aplikaci.

Aplikační kód je již vlastní kód procedury, opět je nutné ho rozdělit na klientskoua serverovou část. Na klientské straně stačí předat argumenty procedury stubu, na ser-verové straně kód implementuje proceduru.

2.1.2 Přenosové protokoly

Samotná síťová komunikace probíhá na rozličných protokolech, použitý protokol zá-visí na konkrétním souborovém systému. Používají se protokoly TCP/IP, IPX, NetBIOSa další. Některé protokoly (například IPX) nejsou routovatelné, proto souborové systémyjich využívající nelze použít v širším nasazení mimo sítě LAN. Všechny zkoumané sou-borové systémy však dokážou běžet i nad TCP/IP.

V rodině protokolů TCP/IP, která je v dnešní době nejrozšířenější, souborové systémypoužívají transportní protokoly TCP i UDP. Oba protokoly mají své klady i zápory.

Protokol TCP zajišťuje spolehlivé doručení packetů ve stejném pořadí, v jakém bylyodeslány, ale je zatížen větším overheadem, který se projeví zejména na pomalejšíchlinkách. Protokol též není vhodný pro nespolehlivé linky, neboť byl navrhován s předpo-kladem, že protokoly nižších vrstev ISO/OSI modelu přenášejí data spolehlivě, a veškeréztráty packetů jsou způsobeny přehlcením přenosové linky. Tento mylný předpoklad sena nespolehlivých linkách projeví drastickým snížením rychlosti přenosu.

Protokol UDP, který se vyznačuje nižší režií přenosu, však nezaručuje spolehlivédoručení, pořadí doručovaných packetů, ani to, že packety nebudou duplikovány. O tytozáruky se musí postarat protokoly vyšších vrstev.

Poměrně důležitým faktorem při provozu souborových systémů v rozlehlých sítích jemožnost propustit souborový systém skrz firewall, která je ovlivněna užitým přenosovýmprotokolem a počtem a čísly komunikačních portů. Aby bylo možno protokol propustit,souborový systém nesmí dynamicky přidělovat čísla portů, musí komunikovat na předemstanovených portech a je vhodné, aby používal omezené množství portů.

Neméně podstatným činitelem při provozu v heterogenních sítích je schopnost tune-lovat protokol. Protokol musí splňovat stejné požadavky jako v případě propustnosti skrzfirewall, navíc nesmí být vázán na konkrétní IP adresu. Například systém SFS ve verzi0.6 svazoval kryptografické klíče s IP adresou serveru.

– 12 –

2.2 Vlastnosti souborového systému

2.2.1 Dostupnost a přenositelnost

Dostupnost, přenositelnost, stabilita a multiplatformní interoperabilita souborovéhosystému patří mezi důležité vlastnosti z hlediska nasazení a provozu systému. Jak jižbylo uvedeno v úvodu, byly vybrány ty souborové systémy, pro něž existuje UNIXovýklient, konkrétně klient pro operačním systému Linux. Ne všechny souborové systémyvšak fungují pouze na platformě UNIX.

Některé souborové systémy byly navrhovány pouze pro konkrétní platformu, ať užpro UNIX, DOS nebo Windows. Takovéto systémy si s sebou nesou nepříjemné „dědic-tvíÿ a špatnou kompatibilitu s ostatními platformami, která je postupem času a vývojesystému dodělávána rozličnými způsoby. Příkladem může být protokol SMB, který byl vesvých počátcích striktně určen pro platformu DOS a Windows, z čehož například plynulaomezení v souborových atributech, přístupových právech nebo jménech souborů. S vývo-jem protokolu byly v novějších verzích přidávány nové vlastnosti, které tehdejší systémyvyžadovaly. Například na Windows 95 dlouhá jména souborů, na Windows NT seznamyACL, apod. Takovýto systém je pak pochopitelně komplikovanější a méně rozšiřitelnýnež systém navrhovaný již od počátku jako platformně nezávislý.

Obecný protokol nezávislý na konkrétním operačním systému však s sebou také nesejistá rizika. Návrh musí být dostatečně prozíravý a rozšiřitelný, aby v budoucnosti mohlpojmout případné nové vlastnosti lokálních souborových systémů, které v době vznikusystému ještě nebyly známy. S poměrně dobrým návrhem v tomto ohledu přichází NFS4,které například umožňuje budoucí rozšiřování vlastností souborů a souborového systémupomocí pojmenovaných atributů.

S interplatformní rozšiřitelností a dostupností úzce souvisí dostupnost dokumentacek protokolu, která je zejména důležitá pro vývoj otevřených implementací. Nicméněi v podmínkách, kdy dokumentace k protokolu je pouze proprietární, lze metodou zpět-ného inženýringu protokolu navrhnout klient nebo server daného síťového souborovéhosystému — příkladem může být klient ncpfs souborového systému Novell.

Důležitý je též stav vývoje protokolu. Většina zkoumaných souborových systémů bylastabilní a široce užívaná, ale například protokol SFS byl stále ve vývoji a dosud nebylprohlášen za stabilní. To se projevilo podstatnou změnou protokolu mezi vydanými ver-zemi a zpětnou nekompatibilitou těchto dvou verzí. Některé protokoly jsou prohlášenyza stabilní a široce se používají, ale přesto se stále vyvíjejí. Příkladem může být protokolSMB/CIFS, jehož vývoj neustále pokračuje vpřed, jsou vydávány stále novější verze pro-tokolu avšak je dodržena zpětná kompatibilita a pokud komunikující strana podporujenějakou verzi protokolu, musí podporovat i všechny nižší verze. Protokol oplývá mechanis-mem vyjednávání verzí, který vždy zaručuje, že každý klient bude schopen komunikovats každým serverem a naopak.

2.2.2 Vlastnosti z klientského hlediska

Uživatelská práce se souborovým systémem začíná připojením systému do UNIXovéhoadresářového stromu. Z tohoto hlediska můžeme sledovat dvě podstatné vlastnosti. První

– 13 –

z nich je možnost připojit souborový systém jako uživatel. Jak je známo, na systémuUNIX může souborové systémy připojovat pouze superuživatel. Běžný finální uživatelvšak práva superuživatele typicky nemá, ale požaduje, aby se mohl připojit k libovolnémuserveru. V tomto ohledu vychází uživatelům vstříc systém SFS, který dovoluje připojovatvzdálené servery libovolnému uživateli. Podobně pracuje systém AFS, který však vyžadujekonfiguraci dostupných buněk superuživatelem.

Vzdálený server může být připojen buďto standardním způsobem do libovolného při-pojovatelem stanoveného adresáře, nebo se připojuje na všech klientech vždy do stejnéhoadresáře. V prvním případě aplikace běžící na klientu přistupuje na souborový systémtransparentně bez vědomosti, že se jedná o vzdálený server. Transparentně lze připojitnapříklad souborový systém NFS. Naopak kupříkladu SFS nebo AFS servery jsou navšech klientech připojovány do adresáře /sfs, respektive /afs.

Některé klienty neumožňují připojovat souborový systém vůbec. Ze zkoumaných sou-borových systémů se jednalo pouze o smbclient z balíku Samba, který nabízí textovéřádkově orientované uživatelské rozhraní podobné textovému FTP klientu.

S připojováním úzce souvisí jmenný prostor. Cesty k souborům u netransparentněpřipojovaných souborových systémů začínají pevně daným prefixem, který typicky jed-noznačně určuje daný souborový systém, připojený server a případně nese ještě nějakoudalší informaci, například u SFS ještě veřejný klíč serveru.

Jména objektů souborového systému se liší podle hostitelské platformy. V operačnímsystému DOS se jméno skládá ze dvou částí oddělených tečkou: z osmiznakového jménaa tříznakové přípony. Na UNIXu je jméno omezeno pouze délkou 255 znaků. Každáplatforma jinak respektuje velká a malá písmena, stejně tak jsou na každé platforměvyhrazeny určité znaky, které se ve jménech objektů nesmí vyskytovat, a používají serůzné oddělovače komponent cesty. Multiplatformní síťový souborový systém musí býtschopen se s těmito odlišnostmi vyrovnat. To lze provést několika způsoby. NapříkladNovell dovoluje ukládat vícero jmenných prostorů pro UNIX, pro DOS, či OS/2. Vět-šina souborových systémů však problém řeší překladem jmen, který lze většinou doladitkonkrétním nastavením klientu respektive serveru. Příkladem nechť je server Samba.

Adresáře lze přenášet buďto jako celek, nebo po jednotlivých položkách. Výhodapřenášení vcelku spočívá v rychlosti, která se projeví zejména u objemných adresářů.

Podobně jako se liší jmenné prostory, najdeme značné odlišnosti i v atributech a pří-stupových právech objektů. Operační systém DOS nabízí pouze čtyři příznaky o typuobjektu, ale neumožňuje u objektů identifikovat vlastníka ani jeho práva. UNIX u kaž-dého objektu ukládá vlastníka, skupinu a bitovou masku přístupových práv pro čtení,zápis, vykonávání a další. Windows NT ke každému objektu přiřazují seznam ACL. Ně-které síťové souborové systémy poskytují pouze UNIXová práva (například NFS, SFS),některé nabízí ACL (Novell, AFS, CIFS). V tomto ohledu je asi nejpokročilejší NFS4,které díky svému důmyslnému mechanismu povinných, doporučených a jmenných atri-butů umožňuje implementovat obé.

Samotné ACL se liší podle práv, které lze ke každému principalu přiřadit, podlezpůsobu aplikace práv, i podle toho, kterým objektům může být ACL seznam přiřazen.

– 14 –

Mechanismus ACL je ve všech případech vpodstatě stejný, práva se liší pouze v detailecha pojmenování (viz například ACL v systému Novell versus v systému AFS). V systémuAFS lze ACL přiřazovat pouze adresářům, na Novellu každému objektu.

Existují dva modely ACL: model POSIX a model použitý ve Windows NT. V mo-delu NT každá položka v ACL seznamu, ACE — Access Control Entry, nabízí čtyři typypřístupu: ALLOW, DENY, AUDIT a ALARM. ALLOW a DENY povolují nebo zakazují principalupřístup k objektu. Je-li nastaven příznak AUDIT a pokusí-li se principal přistoupit k ob-jektu, server přístup zaloguje do systémového logu. ALARM při přístupu na objekt vyvolásystémový alarm, jehož význam závisí na konkrétním serveru a operačním systému. PO-SIXový model ACL podporuje pouze přístupy ACCESS a DENY. V modelu NT rozhodujeprvní souhlasící řádek ACL, zda daný principal dostane povolení nebo zamítnutí přístupu.V POSIXovém modelu existují dva typy ACL — uživatelský a skupinový. Kontrolován jenejprve uživatelský přístup a pokud není jednoznačně povolen nebo zakázán, teprve pakje kontrolován přístup skupiny.

Krom přístupových práv musí souborový systém zajistit kompatibilitu mezi identifi-kací vlastníků objektů, neboť různé architektury používají různé representace identifiká-torů. Tento úkol lze řešit několika způsoby. Jsou-li uživatelé a skupiny identifikováni čísly,systém čísla mezi komunikujícími stranami překládá. Některé systémy se snaží uživateleidentifikovat jednoznačným řetězcem obsahujícím jméno uživatele a DNS doménu. Jinésystémy používají 128 bitové světově unikátní identifikátory UUID ze systému DCE [47].Systém NFS překlad UID neumožňuje vůbec, musí být zajištěn speciální službou.

Problémem řetězcových identifikátorů uživatelů by teoreticky mohla být granularitaidentifikace omezená na doménu. V typickém případě se pravděpodobně nestane, že byna dvou serverech v doméně existoval uživatel se stejným jménem odpovídající dvěmarůzným fyzickým osobám, neboť DNS doména typicky odpovídá jedné organisaci nebopodniku, kde jsou uživatelská jména přidělována jednoznačně pro celou doménu, ale z te-oretického hlediska by tato situace mohla nastat a pomocí řetězcových identifikátorůby nebylo možno tyto dva uživatele rozlišit. V tomto ohledu jsou identifikátory UUIDvýhodnější, avšak jejich význam není natolik intuitivní jako v případě řetězcových iden-tifikátorů.

Z uživatelského a programátorského hlediska je též zajímavé sledovat odlišnosti v sé-mantice od UNIXového souborového systému a zamykací mechanismy, které zkoumanésouborové systémy nabízí.

2.2.3 Cache

Značný dopad na výkon klientu souborového systému má vyrovnávací paměť umístěnána klientu. Cache má za úkol zrychlovat odezvu opakovaných operací, zejména pak čteníze souboru. V nejjednodušších případech úplně chybí a veškeré požadavky jsou vždypropagovány přes síť na server. V jednodušších případech klient do cache ukládá pouzeněkteré informace, příkladem budiž NFS, které ukládá souborové atributy. Dokonalejšísystémy pak umožňují ukládat i data souborů a to buď pouze bloky, nebo celé soubory.V nejlepších systémech cache zachycuje požadavky na čtení i zápis.

– 15 –

Implementuje-li systém datovou cache na klientech, musí též zajistit její synchronisacimezi klienty a serverem. K tomu účelu se používá několik metod. Konsistenci dat pro čtenízajišťuje server. První metoda spočívá v tzv. propůjčování (anglicky leases), kdy server naurčitou krátkou dobu klientu zajistí, že data v jeho cache odpovídají obrazu na serveru,a klient po uplynutí této doby musí o záruku žádat znovu. Jiná metoda zaručuje klientukonsistenci na neurčitou dobu s tím, že v případě změny dat server zašle klientu zprávu,po jejímž přijetí klient data v cache invaliduje. Změny jsou tak propagovány na klienty,byť nejsou přenášena nová data, ale pouze informace o změně.

Synchronisace zápisů je typicky řešena až při zavření souboru. Tento způsob úplněnesouhlasí se sémantikou UNIXového souborového systému, která požaduje, aby se zápispromítl do souboru téměř okamžitě po zavolání write(), pouze se zpožděním vnitřníchvyrovnávacích pamětí operačního systému.

Pokud s daty pracuje pouze jediný klient, souborový systém může používat pro zrych-lení operací transakční přístup. Server může na nějakou dobu přesunout veškerou zodpo-vědnost za data na klient, klient po tu dobu pracuje s daty pouze ve své cache a není nucenkomunikovat se serverem. Po uplynutí vymezené doby klient potvrdí změny v datech naserver. Příklad transakční práce se soubory lze nalézt například v AFS nebo NFS4.

Cache může být vytvořena na disku nebo v paměti. Disková cache je výhodnější,neboť její obsah zůstane zachován i po restartu klientu.

Datovou cache souborového systému často v praxi supluje page cache operačníhosystému. Ta však pouze zrychlí operace, ale nezajistí konsistenci mezi jednotlivými klienty.

2.2.4 Bezpečnost

Nežli je umožněno klientu připojit vzdálený souborový systém serveru, uživatel semusí do systému autentizovat. Autentizace po síti by měla být zabezpečená, aby nebylomožno odposloucháváním sítě odchytit uživatelské heslo či nějakou jinou informaci, kteráby pomohla neautorizovanému uživateli získat přístup do systému. Bohužel ne všechnysystémy používají bezpečný mechanismus autentizace, některé protokoly (například NFSnebo rané verze SMB) dokonce posílají heslo ve formě plaintextu.

Uživatel se může autentizovat buďto přímo serveru, který drží data souborového sys-tému (příklad SFS), nebo se autentizuje k systému jako k celku a po zalogování můžepřistupovat k libovolnému souborovému serveru systému (příklad AFS). Autentizace ty-picky probíhá při přihlášení uživatele do systému, klient při ní obdrží identifikátor, pomocíněhož může oprávněně přístupovat k serverům. Jako identifikátor se používá buď serveremvygenerované číslo (například v systémech NFS, SMB), nebo ticket obsahující v zakryp-tované formě uživatelovu identifikaci, heslo, časová razítka vydání a expirace (příklademmůže být AFS). Systém ticketů používá bezpečnostní protokol Kerberos [21][13].

Systémy autentizující se mechanismem ticketů vyžadují pro svůj provoz časovou syn-chronisaci mezi klienty a servery. K tomu účelu slouží protokol NTP (Network TimeProtocol).

Většina souborových probíraných systémů dovoluje nakonfigurovat na serveru přístuppro anonymní uživatele. Síťový souborový systém pak může fungovat jako anonymní FTP

– 16 –

server, který poskytuje široké veřejnost ke čtení necitlivá data. U některých souborovýchsystémů anonymní přístup lze vytvořit vytvořením uživatele bez hesla.

Z bezpečnostního hlediska je důležité, aby souborový systém neumožnil nepovolanýmosobám číst nebo modifikovat přenášená data. Proti modifikaci přenášených dat se lzebránit kryptografickým podepisováním síťových zpráv. Proti čtení a případnému únikucitlivých dat se lze bránit jedině šifrováním zpráv. Šifrování však zatěžuje procesor oboukomunikujících stran. Tato vlastnost se projeví jako problém zejména u serverů, kterémusí odolat požadavkům mnoha desítek až tisíců klientů. Takovéto servery musí býtosazeny dostatečně silným procesorem, který zvládne šifrovat komunikaci s mnoha klientyzároveň.

2.2.5 Vlastnosti serveru

Servery souborových systémů používají k ukládání dat buďto hostitelský souborovýsystém, nebo ukládají data na disk ve vlastním formátu do speciálního diskového od-dílu. Většina zkoumaných systémů používá hostitelský souborový systém, vlastní formátuložení dat na disku vyžaduje pouze AFS.

Objekty na souborovém systému musí být jednoznačně identifikovány při komunikacimezi klientem a serverem. Klient požadující práci s nějakým objektem tento objekt připrvním použití popíše cestou, případně jménem v adresáři. Server klientu předá identi-fikátor, v některých systémech označovaný jako file–handle, který jednoznačně popisujeumístění objekt na disku serveru. Při další práci s objektem se klient odkazuje získanýmidentifikátorem. Identifikátor objektu musí zachycovat nejen umístění objektu v prostoru,ale i v čase. Zanikne-li jeden objekt a na jeho místě se objeví jiný objekt, identifikátor no-vého objektu se musí lišit od identifikátoru objektu starého. Identifikátor na UNIXovémsouborovém systému typicky vznikne zakódováním čísla disku, čísla inode a generačníhočísla inode. Pro klient je identifikátor souboru nedekódovatelný. Operace, které s nímlze provádět jsou předání serveru a bitové porovnání na shodu, tak lze zjistit, zda dvaidentifikátory popisují tentýž objekt.

Pro větší robustnost, odolnost proti výpadkům a případné vyrovnání zátěže souborovésystémy mohou replikovat nebo migrovat data mezi servery. Data mohou být přemisťo-vána buď na popud administrátora, nebo automaticky. Servery k tomuto účelu používajíspeciální protokoly, které většinou nejsou součástí specifikace daného souborového sys-tému.

Jelikož síť není vždy stoprocentně spolehlivá a může docházet k výpadkům, stejnětak může dojít k havárii klientu nebo serveru, souborový systém by měl být schopen ses krizovými situacemi vyrovnat a po pádu být schopen se dostat do konsistentního stavua sesynchronisovat stav klientů se stavem serveru.

Velice dobrá myšlenka — bezestavový protokol — je představena v protokolu NFS.Tento robustní přístup odstraňuje ze serveru veškeré stavové informace a přesouvá je naklienty, takže po pádu serveru není nutno provádět složité zotavení. Bohužel implementacetéto myšlenky v NFS není příliš šťastná a přináší podstatná bezpečnostní rizika. Více vizkapitola NFS.

– 17 –

3. Měření vlastností souborových systémů

V této kapitole se zaměříme na popis praktických testů a zkoumaných veličin.

3.1 Vytyčení cílů měření

Při práci se souborovým systémem uživatele zajímá zejména rychlost, počet operací,které je souborový systém schopen provést za sekundu, a v případě čtení a zápisu pro-pustnost těchto operací v bytech za sekundu. Krom rychlosti je z uživatelského hlediskazajímavá též latence jednotlivých operací. Čím menší latence a větší propustnost operací,tím lepší je souborový systém pro uživatele.

Krom těchto faktorů můžeme rozlišovat síťové souborové systémy podle nároků nahardware, to znamená na procesor, paměť a síť. Jak moc souborový systém zatěžujeprocesor a paměť klientu a serveru a kolik procent síťového provozu generovaného sou-borovým systémem zabírají režijní data a kolik procent zabírají přenášená data. Mohlibychom též uvažovat požadavky na hostitelský souborový systém a disk, ale tyto jsouv dnešní době podstatně rychlejší než síťové přenosové technologie, navíc zkoumáme vlast-nosti síťového souborového systému a ne lokálního souborového systému. Proto můžemepředpokládat, že rychlost disku a lokálního souborového systému serveru není limitujícímfaktorem v celkové rychlosti a propustnosti síťového souborového systému.

Spustíme-li v praxi server libovolného souborového systému a budeme-li zvyšovatpočet připojených klientů, celkový přenesený objem dat mezi všemi klienty a serveremnebude stále lineárně růst, za předpokladu, že všechny klienty generují stejnou konečnouzátěž, neboť server a zejména síť nejsou nekonečně rychlé. Záhy zjistíme, že přenesenýobjem dat od určitého okamžiku růst přestane . Můžeme se ptát, proč došlo k zastavenía která část systému ho zapříčinila. Úzká místa v systému mohou být tři. První z pode-zřelých míst je disk, řadič a hostitelský souborový systém, který nemusí stíhat dodávatdata dostatečně rychle, druhým je procesor, který nedokáže data na serveru dostatečněrychle zpracovávat, a konečně třetím místem je sběrnice, síťová karta a přenosová linka,které nemusí být schopny přenášet takový objem dat.

Jak jsme řekli, hostitelský souborový systém můžeme považovat za dostatečně rychlý,zbývají tedy dvě úzká místa — procesor a síťová karta. A právě na těchto úzkých místechmůžeme porovnat kvality jednotlivých souborových systémů, jak úsporně jsou schopnyse systémovými prostředky hospodařit, aby dokázaly zpracovat co největší objem datv daném čase.

Cílem našich měření tedy bude jednak zjistit propustnost jednotlivých souborovýchsystémů v prostředí jednoho klientu a dále změřit schopnosti souborového systému v pod-mínkách na hranicích možností hardware a tím zjistit reálné zatížení procesoru a sítěsouborovým systémem.

Nebudeme však sledovat propustnost pouze v optimálních podmínkách, ale takév podmínkách nepříznivých: na pomalých přenosových linkách s netriviálním zpožděníma na síťových trasách s chybovostí. Za těchto podmínek budeme sledovat propustnostsouborového systému.

– 18 –

3.2 Generátory zátěže

Měření spočívala v generování zátěže souborového systému a současném měření růz-ných systémových veličin. Pro snadnější použití a zaručení naprosto stejného prostředíbyla vytvořena soustava shellových skriptů, které automatizovaně provádějí jednotlivétesty. Skripty lze nalézt na přiloženém CD.

Při měření výkonu souborových systémů byly použity syntetické i reálné generátoryprovozu. Generátory zátěže měly za úkol intenzivně provádět operace, jejichž rychlost sepřímo promítá na výkon souborového systému. Pro soubory jsou těmito operacemi čtenía zápis (systémová volání read() a write()). Pro adresáře vytváření a mazání objektu,zjišťování atributů objektu (volání stat()) a čtení adresáře (volání readdir()).

Z reálných generátorů byly vybrány typické UNIXové nástroje pracující intenzivněse soubory a vytvářející netriviální zátěž souborového systému. Reálné generátory zátěžese snažily vytvořit podmínky, které uživatel nastoluje souborovému systému při běžnékaždodenní práci.

Cílem syntetických testů bylo změřit pokud možno přesné hodnoty rychlosti a prů-chodnosti jednotlivých souborových systémů.

Nyní přejdeme k popisu jednotlivých testovacích nástrojů:

3.2.1 Diff

UNIXový nástroj diff slouží k porovnávání souborů a adresářů. Během tohoto testujsou porovnávány dva adresáře zdrojových textů překladače GCC. Test intenzivně čteobsahy adresářů a souborů a zároveň příliš nezatěžuje procesor a paměť klientu, výsledektedy není výkonem procesoru ani paměti zkreslen. Jako alternativa byl uvažován překladaplikace ze zdrojových textů, avšak časový průběh kompilace je příliš ovlivněn rychlostíprocesoru a velikostí paměti klientu a na průchodnosti souborového systému závisí ažu velmi rychlých procesorů. Z toho důvodu byla kompilace zamítnuta.

K testování byl použit program diff z balíku GNU diffutils-2.8.1, za vstupní dataposloužily adresářové stromy zdrojových textů kompilátoru GCC gcc-core-3.2.1 a gcc-

core-3.2.2, každý obsahuje přes 1 800 adresářů a souborů o celkové velikosti 56 MB.Při testování souborového systému Novell vstupními daty byly adresáře linux-2.4.19

a linux-2.4.20 zdrojových textů operačního systému Linux. Každý adresář obsahovalpřes 11 900 adresářů a souborů o celkové velikosti 146 MB. Program diff byl spouštěns parametry -urN. Pro eliminaci zpomalení testu výstupem z programu byl výstup pře-směrován do zařízení /dev/null. Měřenou veličinou byla doba trvání operace porovnánídaných dvou adresářových stromů.

3.2.2 Copy

Tento test je zaměřen na ukládání a čtení bloku dat o velikosti řádu stovek mega-bytů do jednoho souboru. Cíl testu spočívá v zjištění chování souborového systému přilineárním čtení a zápisu velkého objemu dat.

K testování zápisu posloužil UNIXový příkaz cp z balíku GNU fileutils-4.1.Čtení bylo testováno příkazem cat z balíku GNU textutils-2.1. Výstup z příkazu

– 19 –

cat byl přesměrován do /dev/null, aby se při testu eliminoval vliv zápisu na disk kli-entu. V obou případech za vstup posloužil archiv zdrojových textů jádra Linux 2.4.20linux-2.4.20.tar. Velikost kopírovaného souboru byla 146 MB, soubor byl kopírovánz lokálního disku klientu na server. Při měření souborového systému Novell za vstupnídata posloužil soubor src.tar zdrojových textů operačního systému OpenBSD 3.2 o ve-likosti 316 MB. Měřenou veličinou byl čas trvání operace.

3.2.3 Find

Během testu Find je procházena adresářová struktura s velkým množstvím souborůa adresářů, prověřována je operace čtení obsahu adresářů. Jádro testu tvoří UNIXovýnástroj find, který umožňuje vyhledávat v adresářových stromech. Test volá zejménaoperace pro čtení obsahu adresáře a zjišťování souborových atributů.

Použitý program find pocházel z balíku GNU findutils-4.1, za vstupní data po-sloužil strom zdrojových souborů operačního systému OpenBSD 3.2 ports.tar, kterýobsahuje přes 31 000 souborů a adresářů. Při testování souborového systému Novell zavstup posloužil archiv src.tar zdrojových souborů operačního systému OpenBSD 3.2,který obsahuje přes 43 000 souborů a adresářů. Program find byl v uvedeném adresá-řovém stromě spouštěn s argumentem -false, který zaručil, že find bude pouze budeprohledávat adresáře a nebude provádět žádné testy a nebude vypisovat žádný výstup.Ověření, že program s tímto parametrem opravdu prohledává adresáře proběhlo za po-mocí nástroje strace. Výsledkem testu byl celkový čas prohledávání.

3.2.4 Tar

Tento test sleduje chování souborového systému během vytváření a zapisování velkéhomnožství souborů. Test spočívá v rozbalení rozsáhlého souborového archivu UNIXovýmnástrojem tar.

Pro účely testu byl použit GNU tar-1.13, za vstup posloužil balík perl-5.8.0.tar

zdrojových textů interpretu jazyka Perl 5.8.0, který obsahuje celkem přes 3 000 souborůa adresářů o celkové velikosti 46 MB. Při měření souborového systému Novell byl vstupembalík ports.tar z distribuce OpenBSD 3.2 obsahující přes 31 000 souborů a adresářůo celkové velikosti 43 MB. Měřenou veličinou byl opět čas běhu programu tar.

3.2.5 Iozone

Iozone [77] je uznávaným měřícím nástrojem ke zjišťování výkonu jednotlivých operacísoborového systému. Nástroj posloužil k měření výkonu souborových operací read()

a write(). Existují i jiné nástroje, avšak Iozone nabízí nejširší škálu modifikací a měřenía podává nejpodrobnější výsledky. V oblasti měření výkonu souborových systémů je široceuznáván a považován za nejlepší.

Operace čtení a zápisu do souboru byly testovány ve všech modifikacích, které ope-rační systém UNIX nabízí: přímá systémová volání read(), write() i knihovní funkcefread(), fwrite() využívající vyrovnávací paměti v adresním prostoru volajícího pro-gramu. Měřen byl sekvenční přístup, náhodný přístup, opakovaný přístup, čtení od koncesouboru, opakovaný zápis na konkrétní místo v souboru a čtení souboru po pravidelných

– 20 –

intervalech. Čtení i zápisy byly testovány pro různé velikosti souborů i počty čtenýchbytů v jednom záznamu. První část testu se zaměřovala na malé soubory do velikostidesítek megabytů a různé velikosti čtených a zapisovaných záznamů, což je typické pro-středí většiny aplikací. Druhá část testů zkoumala chování souborového systému při prácis velmi velkými soubory o velikosti řádu stovek megabytů, v praxi tyto soubory lze potkatzejména v multimediálním prostředí, ať už se jedná o velké objemy dat záznamu obrazu,videa nebo zvuku.

K testování byla použita verze 3.163. Program Iozone byl spouštěn v automatickémmódu, při kterém byla měřena propustnost i latence jednotlivých operací a zatížení proce-soru klientu. V první části testu byl program Iozone spouštěn s parametry -Q -a -g 16m

-b iozone.xls -+u -f test1.iozone -w, v druhé části s parametry -Q -a -r 512k

-n 128m -g 512m -b iozone.xls -+u.

Nástroj Iozone posloužil při měření propustnosti souborového systému při emulacilinky s chybovostí a omezenou šířkou pásma a při měření maximální vytížitelnosti serveru.Při měření na chybové lince byl program Iozone spouštěn s parametrem -s2m.

Během měření zatížitelnosti serveru byl program Iozone spouštěn v distribuovanémrežimu s parametry -+m distrib.list -s 32m -t6. Soubor distrib.list obsahovalseznam serverů:

192.168.3.35 /mnt /usr/local/bin/iozone






3.2.6 Blkread a blkwrite

Tyto jednoduché nástroje byly vytvořeny pro testování čtení a zápisu. Program bl-

kwrite zapíše zadaný počet megabytů dat do zadaného souboru. Program blkread zezadaného souboru přečte udaný počet megabytů. Oba programy naalokují v paměti místoo velikosti 1 MB a čtou, respektive zapisují po blocích této velikosti standardním systé-movým voláním read() a write().

Během zkoumání chování na pomalé lince programy zapisovaly a četly soubor o ve-likosti 1 MB.

3.3 Sledované veličiny a měřící nástroje

3.3.1 Chrono, měření času

Sledovanou veličinou u reálných generátorů zátěže byl čas běhu jednotlivých testo-vacích programů. Bylo nutno zjistit čas procesoru spotřebovaný v uživatelském módu,v kernelovém módu a čas strávený čekáním na IO operace. Operační systém Linux všakumožňuje zjistit pouze první dva zmíněné časy, čas strávený čekáním na IO operace nelzezískat.

– 21 –

Z toho důvodu bylo nutno měřit celkový čas běhu programu, který byl získán sys-témovým voláním gettimeofday(). Toto volání umožňuje získat systémový čas s přes-ností 1 ms [80]. Získaný čas je však ovlivněn mnoha faktory. Měřený proces může býtpřeplánován a odstaven od procesoru na čas od desítek milisekund do několika sekund.Vliv tohoto faktoru byl minimalizován měřením na nezatíženém systému a nastavenímpriority plánování na hodnotu �20 systémovým voláním setpriority(). Další ovlivněníčasu může být způsobeno nahráváním binárního kódu programu do paměti. Toto zkres-lení se většinou projeví pouze při prvním spuštění testovaného programu, při dalších lzeočekávat, že program bude uložen v některé z cache. První běh testu je delší též z důvodunaplňování diskové cache. Některé vlivy jádra operačního systému, například hospodařenís pamětí nebo plánování, však nelze deterministicky opakovat, natož spolehlivě deteko-vat, změřit či eliminovat, proto nebylo možno během měření nastolit naprosto totožnépodmínky. Z toho důvodu bylo nutno měření opakovat a vhodnou statistikou výsledkyzpracovat.

K měření času běhu jednotlivých testů byl vytvořen program chrono, který lze naléztna přiloženém CD. Program implementuje algoritmus popsaný v [82]. Tento algoritmuszaručuje s 95% pravděpodobností, že naměřený čas se nebude od skutečného času lišito více než 2%. Algoritmus opakovaně spouští testovací program a měří dobu běhu. Popěti spuštěních je za předpokladu normálního rozdělení výsledků měření vypočten 95%interval spolehlivosti pro dobu běhu testu. Je-li polovina délky tohoto intervalu větší než2% střední hodnoty výsledků měření, je test opakován, dokud není tato podmínka splněna.V opačném případě je běh ukončen a výsledkem je střední hodnota naměřených veličin.Maximální počet iterací je omezen číslem 25, což odpovídá velikosti pole s předpočítanýmikvantily Studentova rozdělení. Za výše uvedených podmínek je však tento počet krokůdostačující. Teorii potřebnou k určení intervalu spolehlivosti lze nalézt například v [83].

S přihlédnutím k uvedeným faktorům zkreslení měření času byla délka trvání jednot-livých testů volena přiměřeně dlouhá, aby k dosažení stanovené přesnosti nebylo nutnopříliš mnoho iterací.

3.3.2 Shepherd, měření síťové zátěže

Během všech testů byl též sledován síťový provoz, zátěž procesoru a obsazení pa-měti. Popsané veličiny byly získávány protokolem SNMP a sbírány a měřeny nástrojemShepherd. Tento nástroj jsme společně s Karlem Kulhavým komerčně vytvořili pro firmuGTS. Pro potřeby této práce byl Shepherd upraven a byly odstraněny některé jeho nedo-statky. Shepherd lze nalézt na přiloženém CD, přestože byl pro účely měření upravován,není součástí této práce.

Volně dostupných programů pro vzdálený monitoring síťových rozhraní existuje ně-kolik, v praxi je často nasazován systém MRTG, který je však těžkopádný, nedostatečněflexibilní a nelze s ním provádět příliš hustá měření. Shepherd byl zvolen z důvodu svéholehkého návrhu a snadné možnosti přesného přizpůsobení měřenému prostředí díky zna-losti zdrojových textů a architektury programu.

Na všech sledovaných strojích byla instalována služba SNMP. Sledován byl početpřenesených bytů za sekundu, počet přenesených packetů za sekundu, velikost volné pa-

– 22 –

měti a swapu v megabytech a zatížení procesoru v procentech. Některé systémy všaknedovolovaly některé veličiny získávat, proto byly měřeny pouze dostupné veličiny. Databyla měřena v časových intervalech o délce 1 s, následně byla zpracována do formy grafů.Naměřená data i grafy lze nalézt na přiloženém CD.

3.3.3 Iozone, měření propustnosti souborového systému

Nástroj Iozone nesloužil pouze jako generátor zátěže, ale měřil též časy jednotlivýchoperací a propustnost operací v bytech za sekundu. Nástroj byl též používán při měřenípřístupu z více klientů.

Iozone měří čas pomocí systémového volání gettimeofday() a z počtu přenesenýchbytů vypočítá rychlost operace. Operace jsou prováděny vícekrát v závislosti na velikostisouboru a velikosti bloku. Výsledkem výpočtů je střední hodnota. Podrobnější popisfunkce Iozone lze nalézt v [79].

3.3.4 NistNet, emulace sítě WAN

Provoz síťových souborových systémů byl testován na lokální síti s přenosovou rych-lostí 100Mbps. Pro objektivní posouzení kvalit jednotlivých souborových systémů bylovšak nutné otestovat souborové systémy též v podmínkách prostředí rozlehlých sítí WAN,neboť některé vlastnosti se na rychlých sítích LAN neprojeví a projeví se pouze v pro-středí sítí WAN. Jelikož síť WAN nebyla k dispozici, bylo nutno její vlastnosti emulovatsoftwarově na lokální síti. Mezi rozdílné vlastnosti sítí WAN a LAN, které bylo nutnoemulovat, patří zejména omezení šířky pásma, chybovost a zpoždění.

Software potřebný k emulaci byl vybírán z několika dostupných možností. Omezeníšířky pásma lze dosáhnou použitím traffic–shapingu, který je dostupný v jádře systémůLinux, OpenBSD a FreeBSD. Zpoždění a chybovosti však touto metodou dosáhnout nelze,proto bylo nutné zvolit jiný software. Systém FreeBSD obsahuje softwarový balík Dummy-net, který jakožto součást packetového filtru IPFW obsaženém v jádře FreeBSD umož-ňuje omezit šířku pásma, nastavit chybovost linky, způsobit zpoždění a duplikaci síťovýchpacketů. Podobný balík jménem NistNet [76] existuje i pro operační systém Linux. Vzhle-dem k větším zkušenostem s operačním systémem Linux a jednoduššímu uživatelskémurozhraní byl zvolen balík NistNet.

Emulace probíhala vřazením emulačního routeru mezi klient a server testovaného sou-borového systému. Emulační router sestával z počítače typu PC s operačním systémemLinux a dvěmi síťovými rozhraními, ke kterým byl připojen klient, respektive server. Ope-rační systém na routeru měl za úkol směrovat síťové packety mezi těmito dvěma síťovýmirozhraními a emulovat výše uvedené vlastnosti pomocí softwarového balíku NistNet.

Při emulaci chybovosti 1% a 10% byl program NistNet spouštěn s parametry

cnistnet -a 192.168.3.34 192.168.3.66 --drop 1

cnistnet -a 192.168.3.66 192.168.3.34 --drop 1

respektive

cnistnet -a 192.168.3.34 192.168.3.66 --drop 10

cnistnet -a 192.168.3.66 192.168.3.34 --drop 10

– 23 –

V případě emulace šířky pásma a latence byl NistNet spouštěn s parametry (příkladpro 64kbps a 10ms)

cnistnet -a 192.168.3.34 192.168.3.66 --bandwidth 8192 --delay 5

cnistnet -a 192.168.3.66 192.168.3.34 --bandwidth 8192 --delay 5

3.4 Hardware a software testovacího prostředí

Klienty měřených souborových systémů běžely na počítači AMD K6 200MHz s 64MBoperační paměti, 256MB swapového prostoru, pevným diskem IDE a síťovou kartouEthernet 100BaseTX.

Servery souborových systémů byly nainstalovány na počítači AMD K6–2 450MHz,128MB operační paměti, pevným diskem IDE UDMA 33, řadičem disku HPT370A, sí-ťovou kartou Ethernet 100BaseTX. Souborový systém Novell byl testován na serveruPentium Pro 200MHz, 128MB operační paměti, pevným diskem IDE a síťovou kartouEthernet 100BaseTX.

Klienty a servery byly propojeny switchovaným Ethernetem 100BaseTX half–duplex,během testování systému Novell Ethernetem 100BaseTX full–duplex.

Při emulaci chybovosti, zpoždění a omezené rychlosti sítě byl mezi klient a servervřazen router PC s nainstalovaným operačním systémem Linux 2.4.20 a softwarem Nist-Net, který je popsán výše. Router obsahoval dvě síťové karty Ethernet 100BaseTX, mezikterými směroval packety.

Na všech klientech byl nainstalován operační systém LFS Linux [81] s jádrem 2.4.20a souborovým systémem EXT2.

NFS bylo testováno na serveru s operačním systémem OpenBSD 3.3b, se souboro-vým systémem FFS připojeným s parametrem softdep. Na klientech byly instaloványbalíky nfs-utils-1.0.1, portmap 4 a tcp-wrappers-7.6. Testována byla verze 3 NFSodpovídající implementaci v jádře OpenBSD 3.3b a Linux 2.4.20. Server byl spouštěns parametry -tun4. Za transportní protokol bylo zvoleno UDP, neboť NFS bylo původněnavrženo nad tímto protokolem.

Souborový systém SFS byl testován též na serveru OpenBSD 3.3b se souborovým sys-témem FFS připojeným s parametrem softdep. Testovaná verze SFS byla 0.7.2. Instalacebyla provedena ze zdrojových souborů dle návodu obsaženém v instalačním balíku. Přiinstalaci na systém OpenBSD byl vytvořen port a instalační balík SFS obou verzí protento operační systém. Port i instalační balíky lze nalézt na přiloženém CD. NFS serverbyl spouštěn s parametry -tun4.

Server SMB/CIFS běžel v jádře operačního systému Windows NT4.0 Terminal Servers aplikovaným ServicePack 6 a souborovým systémem NTFS. Na klientu byl instalovánbalík samba-2.2.7a instalovaný ze zdrojových textů a překládaný s výchozími parametry.Komunikace probíhala verzí protokolu NT LAN Manager 4.0.

AFS běželo též na serveru LFS Linux 2.4.20 na souborovém systému EXT2. Původněbyla zamýšlena instalace na Windows NT4.0 Terminal Server s aplikovaným Service-Pack 6, avšak tato se nezdařila, byť instalace a konfigurace probíhala dle návodu [65].

– 24 –

Testováno bylo OpenAFS 1.2.8, na klientu i serveru bylo překládáno ze zdrojových textůs výchozím nastavením. Klientský daemon afsd byl spouštěn s parametry -stat 2500

-daemons 4 -volumes 100 -dcache 1000, velikost klientské cache byla nastavena nahodnotu 70MB. Uvedené parametry byly nastaveny dle doporučení dokumentace [65].

Při testování NFS4 byl na klientu i serveru instalován operační systém Linux 2.5.66s aplikovanými patchi projektu CITI [22]. Serverový daemon nfsd a další nástroje byly in-talovány z balíku nfs-utils-1.0.3. Souborový systém byl připojován programem mount

z balíku util-linux-2.11u s aplikovaným patchem util-linux-2.11u-01-nfsv4 z pro-jektu CITI. Všechny balíky byly překládány s výchozími parametry, souborový systémbyl připojován též s výchozími parametry.

Souborový systém Novell byl nainstalován na serveru NetWare 5. Na klientu bylnainstalován balík ncpfs-2.2.3.tar.gz, který byl překládán ze zdrojových textů sestandardním nastavením. Transportním protokolem bylo UDP.

Veškeré softwarové balíky instalované během testů lze nalézt na přiloženém CD.

3.5 Průběh testů a měřeníMěření každého souborového systému probíhalo ve čtyřech fázích.

1) Běžný provoz. V této fázi byly spouštěny testy Copy, Diff, Find, Tar a Iozone.Sledovány byly časy jednotlivých testů, objem přenesených dat po síti, střednídélka packetu, u testu Iozone propustnost jednotlivých operací.

2) Chybová linka. Během tohoto testu byla nástrojem NistNet simulována chybo-vost přenosové linky 1% a 10% při plné rychlosti linky. K měření sloužil programIozone spouštěný s parametry -s 2m v módu throughput.

3) Zúžení pásma a latence. Během této fáze testu byly postupně nastavoványvšechny kombinace parametrů přenosové linky: rychlost 64kbps, 128kbps, 512kbps,1Mbps a roundtrip 10ms, 100ms, 500ms. Za těchto podmínek byla měřena pro-pustnost operací read() a write() vytvořenými nástroji Blkread a Blkwrite.

4) Vytížení serveru. Tato fáze se zaměřuje na zjištění maximálního zatížení serveruklienty. Během testu byly k serveru připojeny tři klienty, na každém běžely dvaprocesy testu Iozone v módu throughput a byla měřena střední propustnost operacíread() a write().

3.6 Problémy s měřením

3.6.1 Testování systému Novell

Z důvodů dostupnosti nebylo možno ozkoušet Novell server v domácích podmínkách.S laskavým svolením Pracoviště počítačové techniky Právnické fakulty University Karlovybylo však možno tento systém s jistými omezeními ozkoušet na nainstalovaném provoz-ním serveru. Z uvedených důvodů se podmínky testování souborového systému Novellliší od podmínek, ve kterých byly provozovány ostatní systémy. Konfigurace klientu zů-stala stejná, lišila se konfigurace serveru, jehož hardwarové nastavení bylo popsáno výše.Prostředí pochopitelně nebylo vyhrazeno pouze testovacím účelům, nicméně okolní vlivybyly eliminovány v maximální možné míře.

– 25 –

Krom testovacího prostředí se lišila i sada pouštěných testů. Z technických důvodůnebylo možno provádět všechny testy, pouze základní sadu ve standardních podmínkách.

Vstupní data testů Copy, Diff, Find a Tar byla použita jiná. Jelikož se ukázalo, žetestovaná data jsou z časových důvodů díky své přílišné velikosti nevhodná pro častéopakování testů, byla později v ostatních testech nahrazena daty menšími. Bohužel jižnebylo možno testy systému Novell provést znovu, proto bylo nutno výsledky získanéz měření systému Novell převést do podoby ekvivalentní výsledkům ostatních měření.

Při převodu výsledků testu Copy jsme předpokládali lineární závislost délky trvánítestu a počtu přenesených dat po síti na velikosti vstupních dat. U testu Copy byly hod-noty vynásobeny poměrem velikostí vstupních souborů, koeficient byl roven číslu 0.461.Časový koeficient pro test Tar byl vypočten shodně a byl roven hodnotě 0.426.

U testů Find a Diff byl koeficient pro dobu běhu vypočítán z poměru výsledků testuspuštěném na obou typech vstupních dat na lokálním souborovém systému serveru. Koe-ficient pro Find byl roven 1.990 a pro Diff 0.179. Koeficienty pro velikosti přenesených dattestů Find, Diff a Tar byly vypočteny z poměru objemů přenesených dat příslušného testuspuštěného na oba typy vstupních dat na souborovém systému NFS, neboť se předpoklá-dala shodná závislost pro oba souborové systémy. Pro test Diff byly koeficienty rovny 0.451pro příchozí data a 0.535 pro odchozí data. Pro test Find byly koeficienty 1.811 pro pří-chozí data a 2.97 pro odchozí data. Pro test Tar koeficienty činily 0.126 pro příchozí dataa 0.837 pro odchozí data.

3.6.2 Ovlivnění výsledků

V některých případech testů během měření nastal problém s přesností výsledků. Jakjiž bylo uvedeno, měření času bylo ovlivněno mnoha faktory operačního systému, kterénebylo možno odstranit. V několika případech testů se časy jednotlivých měření lišilynatolik, že výsledná vypočítaná hodnota neodpovídala zvolené přesnosti, přestože celýtest byl několikrát opakován.

Hlavní příčinou těchto nepřesností byly vyrovnávací paměti v jádře Linuxu pro prácise souborovým systémem. Během prvních dvou iterací testů se naplňovaly vyrovnávacípaměti, proto test trval výrazně delší nebo kratší dobu než ostatní testy, podle toho,zda inicializace testu měla za vedlejší efekt pro test příznivé, nebo nepřiznivé naplněnívyrovnávacích pamětí v jádře. V dalších iteracích již byl stav vyrovnavacích pamětí přispouštění testu přibližně stejný. V případech, kdy inicializace nadměrně zkreslovala vý-sledky testu, nebyla počáteční iterace do výsledků počítána.

Ve fázi měření v zúženém pásmu výsledky operací čtení a zápisu silně zkreslovala pagecache v linuxovém kernelu. Operace probíhaly v paměti, aniž by docházelo ke komunikacise serverem. Proto bylo nutno pracovat se soubory většími než velikost page cache, [79]doporučuje minimálně dvakrát větší soubory než velikost RAM. Z důvodu délky trvánítestů však nebylo možno tak velké soubory použít, proto bylo nutno zmenšit velikostcache. Velikost cache nelze přímo nastavit, neboť buffer cache Linuxu není pevná a za-bírá většinu nevyužité operační paměti. Velikost byla tedy omezena nepřímo zmenšenímvelikosti operační paměti na 12MB.

– 26 –

Při zkoumání chování souborových systémů na chybové lince byla velikost souboru2 MB vybrána s ohledem na dobu běhu testu, neboť se oprávněně předpokládalo, žepři vysoké chybovosti se rapidně sníží propustnost souborového systému. Bohužel, jak sepozději ukázalo, v některých případech výsledky zkreslila page cache Linuxového kernelu.

U testu Iozone též byly výsledky výrazně ovlivněny paměťovou cache, z toho důvodubyly měřeny operace se soubory do 256MB, tedy minimálně do dvojnásobku velikostioperační paměti serveru i klientu, jak doporučuje dokumentace k Iozone [79].

– 27 –

4. Network File System

4.1 Úvod

Ve světě operačních systémů UNIX [15] se pro sdílení souborů ukotvil jako standardsíťový souborový systému NFS, který je dostupný prakticky na všech odnožích UNIXu.Architektura tohoto souborového systému je klient–server, NFS server nabízí své adresářevzdáleným klientům, kteří si je mohou připojovat do své adresářové struktury. Z klientskéstrany se souborový systém chová jako lokální, lze jej transparentně připojovat pomocístandardního příkazu mount a používat naprosto shodně jako lokální souborový systém.

4.2 Historie

Systém NFS byl vyvinut počátkem 80. let minulého století firmou Sun Microsystemsjako standard pro výměnu dat mezi rozdílnými architekturami a systémy. Od té dobyvznikly čtyři významné verze. Verze 1 byla pouze prototypem a nikdy nebyla zveřejněna.

Verzi 2 Sun Microsystems poprvé uvolnil v roce 1985. Tato verze byla licencovánamnoha výrobcům UNIXu a koncem 80.let minulého století vznikla na University of Ca-lifornia v Berkeley též volně šiřitelná implementace. Během desetiletého života druhéverze NFS bylo provedeno mnoho drobných nedokumentovaných změn ve specifikaci [10],například někteří výrobci umožnili číst nebo zapisovat více než 4kB datové bloky v jed-nom kuse, jiní například zvýšili počet skupin, které jsou součástí RPC autentizace, z 8na 16. Nicméně i přes tyto nekompatibility systém NFS ve verzi 2 zavedl pozoruhodnouslučitelnost mezi platformami různých výrobců a jako standard byl vydán v [1].

Základy specifikace verze 3 byly položeny během série konferencí v Bostonu v poloviněroku 1992, jako standard tato verze vyšla roku 1995 v [3] na základě článku [2] uvedenémv létě 1994 na konferenci USENIX. Verze 3 přináší mnoho drobných úprav pro zlepšenívýkonu jako například asynchronní zápis či lepší zázemí pro cacheování, dále 64 bitovýprotokol, ale na vlastním principu ani bezpečnostním modelu se nic zásadně nemění. Zesíťového hlediska přišla pouze jedna podstatná změna — NFS ve verzi 3 může používattransportní protokol TCP i UDP. V této práci se budeme zabývat verzí 3 protokolu NFS.

Dosud poslední verze protokolu, NFS4, přinesla mnoho změn a vylepšení, protokol seve většině směrů od předchozích verzí podstatně liší a má pouze málo společného, prototuto verzi budeme zkoumat zvlášť jako jiný souborový systém.

Dnes je podpora NFS rozšířena již do mnoha systémů. Prakticky ve všech UNIXechnajdeme nativní podporu v jádře a daemony standardně v distribucích. Přestože NFSpochází ze světa UNIXu, najdeme též několik implementací pro Windows, Solstice firmyWRQ, ProNFS od Labtam Inc., komerční OmniNFS od firmy Xlink nebo PC-NFS firmyOmniplex. Všechny zmíněné produkty s výjimkou ProNFS lze získat zdarma na webovýchstránkách dotyčných firem v omezené demo verzi pro účely ozkoušení.

4.3 Síťová architektura

NFS stojí nad rodinou protokolů TCP/IP, na transportní vrstvě využívá protokoluUDP, od verze 3 je možno zvolit mezi TCP a UDP, v obou případech NFS komunikace

– 28 –

probíhá na portu 2049. Samotné NFS nekomunikuje přímo s transportní vrstvou, alevyužívá služeb dvou dalších komunikačních vrstev — relační a presentační, které jsouzajišťovány protokoly RPC [5][6][7] a XDR [8][9].

Vrstva Název Protokol

7. Aplikační NFS

6. Presentační XDR

5. Relační RPC

4. Transportní TCP nebo UDP

3. Síťová IP

2. Linková Ethernet1. Fysická

Tabulka 1: Zařazení NFS do modelu ISO/OSI.

Zařazení protokolu NFS do ISO OSI modelu zobrazuje tabulka 1. Na nejnižších vrst-vách OSI modelu nemusí nutně sídlit Ethernet, který byl uveden pouze jako příklad, alejakákoliv přenosová technologie, nad kterou běží TCP/IP.

4.3.1 Sun RPC a XDR

Systém NFS využívá ke svému běhu protokolu vzdáleného volání funkcí od firmySun Microsystems. Konkrétně se jedná o dva protokoly: RPC zajišťující vzdálené volánífunkcí a XDR zajišťující platformně nezávislý přenos dat. Oba protokoly byly vydányjako standardy RFC [5][6][8][9].

RPC i XDR používají k přenosu po síti protokol UDP, od NFS verze 3 také TCP,v obou případech transportní komunikace probíhá na portu číslo 111. Protokol UDP bylpůvodně zvolen z toho důvodu, že vzdálená volání funkcí mívají většinou krátkodobýcharakter, typicky se přenáší malé množství dat, navazování a následné zavírání spojeníby tedy přinášelo příliš velkou režii přenosu. S použitím UDP jakožto nespojovanéhonespolehlivého protokolu, který nezajišťuje doručení dat ani správné pořadí přijetí ode-slaných zpráv, bylo nutné zavést jistá opatření při návrzích protokolů. Protokol musí býtodolný proti ztrátě přenášené zprávy a každá RPC zpráva musí obsahovat dostatečnouinformaci o kontextu, ve kterém je vzdálené volání prováděno. RPC volání mají specifi-kovánu maximální dobu čekání, do které by měl klient obdržet od serveru odpověď, kdyžji však nedostane ohlásí chybu, nebo požadavek zopakuje. Maximální počet opakováníudává parametr systému, který na klientu i serveru nastavuje systémový administrátor.S použitím přenosového protokolu TCP všechny tyto problémy odpadají.

Podporu protokolu RPC na obou komunikujících koncích zajišťuje speciální daemon,který je spuštěn při startu systému. Teoreticky by bylo možné, aby tento daemon bylspouštěn super–daemonem inetd při každém připojení klientu na server, ale jelikož službyRPC mají jednorázový charakter a jsou volány často, systém serveru by byl zatěžovánzbytečnou režií.

Volání RPC jsou jednoznačně identifikována číslem služby a v rámci služby ještě čís-lem volání. Seznam názvů a čísel služeb lze nalézt v souboru /etc/rpc, služba NFS je

– 29 –

například identifikována číslem 100003. Aby klient mohl zjistit, na kterém portu vzdále-ného serveru sídlí požadovaná služba, na serveru vždy běží služba portmap poskytovanástejnojmenným daemonem, jež klientu sdělí číslo transportního portu, na který se klientmá připojit, aby mohl vykonávat volání příslušné služby. Chce-li tedy klient napříkladsmazat soubor na NFS, kontaktuje nejprve portmap, aby zjistil, na kterém portu sídlíslužba NFS, portmap vrátí číslo transportního portu, na které klient následně navážesíťové spojení, a pak již komunikuje pouze s nfsd běžícím na daném portu 1).

Klientský stroj

Klientskýprogram

Serverový stroj

Serverovýprogram

Portmaper

port B

port C

port A

2

1

3

Obr. 2: Navazování RPC komunikace pomocí portmapperu.

Obrázek 2 ukazuje, jak probíhá komunikace s portmapperem:

1. RPC server, obsluhující službu S (například 100003 v případě NFS), začne na-slouchat na portu A (v případě NFS 2049), na kterém hodlá vyřizovat požadavky.Kontaktuje portmapper a zaregistruje číslo služby S společně s portem A.

2. Klient, který chce komunikovat se serverem, kontaktuje portmapper na serverovéstraně a dotáže se, na kterém portu sídlí server obsluhující službu S. Portmappervrátí klientu číslo portu A.

3. Klient naváže spojení se serverem na portu A a provede vzdálené volání funkce.

4.3.2 Bezestavovost

Celý systém NFS je navržen jako bezestavový. Tato vlastnost vychází z původníhopoužití transportního protokolu UDP, který je taktéž bezestavový. Výhoda bezestavo-vosti spočívá v tom, že klient ani server si nemusí pamatovat nic z předchozích relací, cožznačně ulehčuje a zprůhledňuje implementaci. Při případném pádu ať klientu či serveru,rozpadnutí síťového spojení a následném obnovení lze bez problémů pokračovat v před-chozí započaté práci, aniž by bylo nutno složitě obnovovat spojení, obnovovat práci, čisnad dokonce odstraňovat následky havárie. Při pádu serveru stačí, aby klient opakovalžádost, dokud server neodpoví. V případě, že by komunikace byla stavová, klient by při

1) Příklad popisuje obecný postup RPC komunikace. NFS je speciální případ, kdy je port serveru pevně

dán, má číslo 2049

– 30 –

pádu musel buďto zdetekovat stav serveru a navrátit server do stavu před pádem, neboprohlásit operaci za neúspěšnou. S protokolem UDP není nutno v případě pádu ani na-vazovat znovu spojení jako při použití TCP. Server je z výše uvedených důvodů navrženjako „hloupýÿ a klient jako „chytrýÿ, to znamená, že server pouze odpovídá na požadavkyklientu a veškerá inteligence je umístěna v klientu, obecně klient má na starost zajištěnízotavení z pádu.

Všechny operace jsou navrženy jako idempotentní, aby případná duplikace síťovézprávy nepoškodila data nebo neprovedla nezamýšlenou operaci. Některé operace z prin-cipu idempotentní být nemohou, například smazání souboru, neboť druhý pokus o sma-zání souboru vrátí chybovou hlášku o neexistenci souboru. Proto většina implementacíserverů idempotentnost takovýchto operací simuluje udržováním krátké historie posledněprovedených operací. Přijde-li opakovaný požadavek, který se shoduje s některým zezáznamů v historii serveru, požadavek je tiše ignorován a ani nedojde k vygenerováníchybové hlášky. Některé starší implementace serverů toto neumí, což je doprovázeno zají-mavými, leč nepříjemnými efekty, kdy například zmiňované smazání souboru při duplikacisíťové zprávy skončí s chybou „No such file or directoryÿ, ale server soubor přesto smaže.

4.4 Model souborového systému

VFS

Lokálnísouborovýsystém

Lokálnídisk

rozhraní systémových volání

Uživatelskáaplikace

VFS

Lokálnísouborovýsystém

Lokálnídisk

KLIENT SERVER

NFS klient NFS server

volání RPC/XDR

KERNELMODE

USERMODE

Obr. 3: Architektura NFS klientu a serveru v operačním systému Li-nux.

NFS není závislé na operačním systému, nedefinuje konkrétní representaci dat nadisku serveru, nevyjmenovává, které operace musí server poskytovat, definuje pouze roz-hraní komunikace a operace, které by měl klient a server podporovat. Pokud hostitelskýoperační systém některé operace neumožňuje, server je nemusí implementovat. NFS tedynemusí nutně plně odpovídat sémantice žádného existujícího souborového systému, imple-mentace serveru se pokouší o „maximální snahuÿ kompatibility s UNIXovým souborovýmsystémem.

Obrázek 3 znázorňuje propojení architektury souborového systému NFS s rozhranímvirtuálního filesystému VFS v Linuxu. Systémové volání souborového systému z klientské

– 31 –

aplikace prostupuje skrze vrstvu VFS do NFS klientu, který komunikuje se serverem.Dostane-li server požadavek RPC, skrze vrstvu VFS získá příslušný objekt z lokálníhosouborového systému a vrátí odpověď klientu. V některých implementacích může serverběžet v uživatelském módu, v operačním systému Linux je server umístěn v jádře, přestožena serveru běží daemon nfsd. Tento daemon vytváří pouze obal, ve skutečnost je veškerýkód umístěn v jádře.

Z pohledu NFS vypadá souborový systém jako orientovaný acyklický graf jehož vr-choly s výstupním stupněm nula jsou soubory. Počet komponent cesty může být limitovánklientským nebo serverovým operačním systémem. Objekty souborového systému NFSodpovídají objektům souborového systému UNIX, soubory jsou považovány čistě za po-sloupnost bytů, nejsou nijak vnitřně interpretovány nebo strukturovány.

Při analýze cesty k objektům souborového systému NFS zpracovává cestu po kom-ponentách, v jednom okamžiku pouze jednu komponentu cesty, neboť různé operačnísystémy používají jiné separátory adresářů v cestě a proto není možné zpracovávat cestujako celek. Protokol přenáší obsahy adresářů vcelku.

Sémantika UNIXového souborového systému zaručuje, že smazání otevřeného souboruse projeví až po zavolání systémového volání close(). Na NFS bylo toto řešeno ne nastraně serveru, neboť celý systém musí být bezestavový, ale na straně klientu. Pokud jetedy na otevřený soubor klientem zavolána operace remove(), klient soubor nesmaže, alepouze přejmenuje na .nfsXXXX, kde XXXX je jednoznačně identifikující přípona v rámciklientu. Jakmile všechny aplikace pracující se souborem tento zavřou, je soubor smazán.Tento mechanismus funguje pouze v rámci stejného klientu. Pokud má soubor otevřenýklient klientA a jiný klient klientB soubor smaže, tento mechanismus se neuplatní,neboť informaci, že soubor je otevřený, zná jedině klient klientA. NFS díky bezestavovostineumožňuje tuto informaci distribuovat serveru nebo ostatním klientům.

NFS používá synchronní RPC volání, po úspěšnému návratu z funkce NFS, je za-jišťěno, že operace proběhla a všechna data jsou v dobře definovaném stavu uloženana disku. Pokud tedy například klient zavolá funkci pro zápis dat do souboru write()

a tato funkce skončí úspěšně, klient si může být jist, že data jsou na serveru zapsána.Synchronní operace jsou WRITE (s parametrem stable nastaveným na FILE SYNC), CRE-ATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK a COMMIT. Protokol ve verzi 3přichází s možností asynchronního zápisu (procedura WRITE je použita v kombinaci s COM-MIT). Asynchronní zápis se vyvolá nastavením parametru stable na hodnotu DATA SYNC.Procedura COMMIT zaručí bezpečné uložení předchozích asynchronních zápisů, případněklientu oznámí, že je nutno data poslat znovu.

NFS verze 3 podporuje krom běžných souborů a adresářů také speciální UNIXovéobjekty jako speciální zařízení bloková a znaková, odkazy, symbolické odkazy, socketya soubory typu FIFO. Atributy souboru odpovídají UNIXovému souborovému systému(viz struktura fattr, [3] strana 22), stejně tak přístupová práva ([3] strana 23). Jménoadresáře „.ÿ odpovídá aliasu pro aktuální adresář, jméno adresáře „. .ÿ odpovídá ali-asu pro rodičovský adresář. Pokud je jméno souboru delší než maximum (získané funkcíPATHCONF), záleží interpretace na nastavení parametru no trunc, je-li nastaven na hod-

– 32 –

notu FALSE, jméno je tiše zkráceno na maximální délku, v opačném případě operaceskončí s chybou NFS3ERR NAMETOOLONG.

NFS identifikuje objekty 24 bitovými nebo 32 bitovými identifikátory file–handle. Pře-vedení struktur popisujících soubor v serverově hostitelském souborovém systému nafile–handle a obráceně je ponecháno na konkrétní implementaci NFS. Klient může získatidentifikátor pomocí procedur MOUNT a LOOKUP. Ve většině implementací NFS file–handlevznikne zakódováním čísla disku, čísla inode a generačního čísla inode.

File–handle se může stát neplatnou nebo může vypršet, když inode, na který naserverovém hostitelském souborovém systému odkazuje, je uvolněn či použit pro jinýobjekt. NFS neobsahuje žádný mechanismus, kterak klientům propagovat změnu inodena serveru, server pouze dokáže rozhodnout o platnosti dané file–handle. Pokud klientprovede RPC volání a předaná file–handle neodpovídá inode, příslušná operace skončís chybou „stale file handleÿ. Neplatná file–handle odkazuje na neobsazený inode, nebonesouhlasí generační číslo inode.

První file–handle representující kořen exportované adresářové struktury získá klientzvláštní RPC mount službou. Na serveru běží daemon rpc.mountd, jemuž klient pošlecestu kořenového adresáře, daemon po úspěšné autentizaci pošle v odpovědi příslušnoufile–handle.

4.4.1 Zamykání

Protokol NFS neumožňuje zamykání souborů, neboť je celý navržen jako bezestavovýa informace o zamčení souborů vnáší do systému stavovost. Proto je zamykání souborůtypu SystemV pomocí fcntl() (zamykání typu SystemV) řešeno zvláštním RPC proto-kolem, který obstarávají daemony rpc.lockd a rpc.statd. První daemon běží na serverui klientu a zajišťuje samotné zamykání, druhý daemon běží pouze na serveru, stará seo konsistenci stavů mezi klientem a serverem a řeší zotavení z pádu.

Komunikace probíhá následovně: Z uživatelského programu přijde systémové volánís žádostí o uzamčení souboru, to se předá lokálnímu rpc.lockd daemonu, který žádostpošle serveru, daemon rpc.lockd na serveru soubor zamkne a rpc.statd začne monito-rovat dostupnost klientu.

Stavová informace o zamčených souborech leží na serveru, když dojde k pádu serveru,server požádá všechny klienty o znovuobnovení zámků. V případě pádu klientu nikdozámek neodstraní, ale po restartu rpc.statd na serveru detekuje nekonsistenci mezistavem uloženém na serveru a stavem, který oznamuje klient. V tomto případě rpc.statdoznámí rpc.lockd na serveru, že je potřeba zámky obnovit, rpc.lockd na serverovéstraně vyzve klient k obnovení zámků do určité časové lhůty (typicky 45 sekund). Pokuddo té doby zámky nejsou obnoveny, server je zruší. To typicky nastane v případě páduklientu, neboť klient většinou při pádu ztratí informaci o zamčených souborech.

4.4.2 Cache

Verze 3 protokolu přinesla z důvodu zvýšení výkonu změnu většiny procedur pracují-cích s objekty souborového systému. Tyto procedury v odpovědi vrací klientu též atributy

– 33 –

objektu, s kterým procedura pracovala, neboť bylo zjištěno, že poměrně nezanedbatel-nou část operací (řádově procenta až desítky procent) souborového systému tvoří právězjišťování atributů a jejich nastavování [10].

Z důvodu častého volání funkcí GETATTR a SETATTR NFS klient ukládá atributy ob-jektů do vyrovnávací paměti. Jestliže jsou atributy souboru čteny, zůstanou ještě krátkoudobu v cache (typicky 3 sekundy). Když klient modifikuje soubor (například volánímwrite()), v lokální kopii se změní pouze atributy času a velikosti a platnost cache seprodlouží o další časový úsek, s výjimkou volání chmod(). Pokud atributy zůstanou ne-změněny po delší dobu (typicky 60 sekund), data z cache se zapíší na server a cache sezneplatní. Stejný mechanismus funguje pro adresáře s tím rozdílem, že minimální čas, pokterý atributy zůstanou v cache, je delší (typicky 30 sekund). Pokud na NFS překládámepříkazem make, můžeme se setkat s nepříjemným efektem, když na jednom klientu modi-fikujeme zdrojový soubor a na druhém pustíme kompilaci, příkaz make prohlásí „Nothingto be done for ’all’ÿ a musíme chvíli čekat, než dojde k vypršení atributové cache.

Některé klienty obsahují read–ahead cache na ukládání dat souborů, specifikace da-tové cache však není součástí standardu [3] a její návrh i implementace jsou v rukouvýrobce klientu. Konsistence cache je zajišťována pomocí souborových atributů, kon-krétně pomocí času poslední modifikace souboru. Pokud jsou data v cache novější než časmodifikace souboru, pak data v cache zůstanou platná, v opačném případě cache musíbýt vyprázdněna. U systémů s mapovanými stránkami se bere za čas modifikace příznak„validÿ u cacheované stránky. Jestliže klient vůbec nemodifikuje čtený soubor, soubormůže v cache zůstat neomezeně dlouho.

4.5 Zabezpečení

Bezpečnost NFS sestává z několika částí. Primárním testem přístupu k souborůmje kontrola adresy klientu, server porovnává IP adresu klientu s databází adres, ze kte-rých je povolen přístup, uloženou v souboru /etc/hosts.allow. Neshoduje-li se adresas žádnou z adres v databázi, server klientu přístup odmítne. Stejným způsobem je možnékontrolovat přístup z privilegovaného portu a případně přístup zamítnout.

4.5.1 Autentizace

Druhým krokem kontroly oprávnění k dané operaci je autentizace uživatele. Ta je zalo-žena na autentizačním mechanismu RPC protokolu, který nabízí několik typů autentizač-ních schemat: AUTH NONE, AUTH UNIX, AUTH DES a AUTH KERB. Nejjednodušší autentizaceAUTH NONE povoluje přístup všem uživatelům. AUTH UNIX patří mezi v praxi nejpoužíva-nější, každý RPC požadavek obsahuje uživatelovy osobní údaje: efektivní UID, efektivníGID a seznam všech GID, kterých je uživatel členem, údaje jsou předávány v nekryp-tované podobě. Na základě těchto údajů server provádí autentizaci uživatele pro danouoperaci. Problémem bývá, když je uživatel členem příliš mnoha skupin. Počet skupinv NFS požadavku je omezen typicky na 8 nebo 16 skupin. Pokud uživatel patří do víceskupin, než je maximální povolený počet, požadovaná operace selže.

Standardy NFS [1][3] nespecifikují autentizační mechanismy AUTH DES a AUTH KERB,tyto bezpečnostní mechanismy jsou implementovány pouze v klientech a serverech ope-

– 34 –

račního systému Solaris, proto nejsou příliš rozšířené a ani nebyly zkoumány. Oba me-chanismy používají namísto uživatelských ID k autentizaci uživatelské jméno, které musíbýt shodné pro klient i pro server, mapování mezi uživatelským jménem a UNIXovýmičíselnými identifikátory UID je ponecháno na konkrétním systému. V autentizačním me-chanismu AUTH DES je použit kryptovací algoritmus DES [52], relační klíče se vyměňujípomocí schematu veřejných klíčů Diffie-Hellman [12], v mechanismu AUTH DES je pou-žit algoritmus DES a princip výměny tajných klíčů Kerberos [13]. [11] popisuje aspektypoužití autentizačních protokolů RPCSEC GSS [19] a Kerberos 5 [21] v souborovýchsystémech NFS 2 a 3.

4.5.2 Mapování uživatelů a skupin

NFS bylo původně navrženo pro spolupráci se systémem NIS pro správu konfigu-račních souborů, bylo určené pro provoz v homogenním síti, kde všechny počítače majístejnou konfiguraci, zejména soubor /etc/passwd. Autentizační mechanismus AUTH UNIX

povoluje přístup k objektům souborového systému na základě UID a GID, z toho dů-vodu server i klient musí používat stejné mapování uživatelských a skupinových jmen naUID a GID. Není-li na systému nainstalován NIS, mapování se většinou provádí statickysynchronisací databází uživatelů /etc/passwd. Není však vyloučeno i mapování jinýmmechanismem, ovšem to není součástí specifikace NFS.

Některé implementace používají na klientech speciální daemon rpc.ugidd, který pro-vádí mapování uživatelů z klientských UID a GID na serverové UID a GID. V případěpoužití tohoto daemonu server musí umět těchto služeb využít. Daemon rpc.ugidd bo-hužel přináší bezpečnostní problém, neboť je možné pomocí této služby zjistit seznamuživatelů na klientském stroji. Tomu lze částečně zabránit porovnáním IP adresy se sou-borem /etc/hosts.allow, nicméně z povolených adres může seznam uživatelů získatkdokoliv.

Ne vždy je žádoucí, aby se uživatelská ID mapovala jedna ku jedné. Zejména neníbezpečné, aby superuživatel na klientském stroji byl považován za superuživatele nastraně serveru. Podobně může být žádoucí mapovat i jiné uživatele nebo někdy je dokoncenutné, aby všichni uživatelé přistupovali na server jako na anonymní FTP. Z toho důvoduNFS nabízí možnost mapovat uživatelská čísla na anonymního uživatele. K tomu slouží nastraně serveru volby root squash, squash uids, squash gids, all squash a anonuid,anongid v konfiguračním souboru /etc/exports.

4.5.3 Bezpečnostní problémy

Většina operačních systémů kontroluje přístup uživatele k souboru pouze při ote-vření souboru, následující operace pak probíhají již bez kontroly přístupových práv. NaNFS tento postup není možný díky bezestavovosti serveru, proto NFS server kontrolujeoprávnění přístupu k souboru při každé operaci.

Na lokálním souborovém systému uživatel může otevřít soubor, zakázat k němu všemuživatelům přístup a pak do něj ještě zapisovat, neboť soubor je stále otevřený. Na NFSby díky bezestavovosti tento zápis do souboru selhal. Aby chování NFS bylo kompatibilnís lokálním souborovým systémem, server musí umožnit přístup k souboru nehledě na

– 35 –

nastavení přístupových práv a kontrolu přístupu k souboru na základě přístupové maskypráv přenechat klientu.

Veškerá bezpečnost NFS závisí na bezpečnosti předávaných file–handle. Jak bylouvedeno výše, počáteční file–handle klient získá od daemonu mountd. Ten dovolí připojenípouze vyjmenovaným klientům identifikovaným IP adresou, NFS počítá s tím, že žádnýpočítač nemůže obdržet platnou NFS handle, aniž by byl autorizovaným klientem.

File–handle se typicky skládá z ID lokálního hostitelského souborového systému, nakterém soubor sídlí, inode souboru a generačního čísla inode. Tato čísla ovšem mohoubýt útočníkem snadno uhodnuta i bez jakéhokoliv odposlouchávání komunikace. Jako IDsouborového systému se typicky v praxi používá číslo fyzického zařízení, číslo inode koře-nového adresáře, které může být použito pro identifikaci exportovaného adresáře, je vždy2. Takže mnohdy útočníkovi brání v uhodnutí file–handle pouze neznalost 32 bitovéhogeneračního čísla. Generační čísla ovšem nejsou vždy vytvářena dobrým náhodným ge-nerátorem, v tom případě je bezpečnost silně ohrožena.

Důležitým bezpečnostním rizikem je možnost spouštění suid programů. NFS totoumožňuje, ale nabízí volbu zákazu přenášení suid bitu.

NFS používá velmi důvěřivý bezpečnostní model: server bezmezně věří klientům v síti,veškerá data, včetně klíčových file–handle jsou přenášena v plain textu a předpokládá se,že data jsou přenesena v nezměněné formě a po cestě nedojde k jejich odposlechu třetíosobou. Obecně návrh NFS předpokládá, že klienty jsou natolik zabezpečené, že uživatelénemohou neoprávněně získat privilegia superuživatele. Z praxe víme, že tyto požadavkyjsou poněkud naivní. Proto NFS není vhodné pro provoz na důležitých serverech, anik ukládání citlivých dat nebo dat, o která nechceme přijít.

Útočník, který má možnost připojení vlastního počítače k síti a jehož IP adresa je naserveru v seznamu adres s povoleným přístupem, může modifikovat svůj klient a tím obe-jít kontrolu přístupových práv. Kdokoliv na cestě mezi klientem a serverem má možnostodposlouchávat data v plain textu, díky použití bezestavového protokolu RPC lze velmisnadno modifikovat soubory. Útočníkovi na síti brání v neomezenému přístupu k datůmpouze neznalost file–handle, proto musí odposlouchat file–handle pro kořenový adresářnebo adresář, do kterého chce mít přístup. S file–handle kořenového adresáře útočník au-tomaticky získává neomezený přístup ke všem souborům exportovaného adresáře včetněmožnosti podvrhování dat a pokud je adresář exportován i pro zápis, útočník může mo-difikovat veškerá data zpřístupněná na NFS.

Nejsme-li na bezpečné síti a exportujeme-li souborový systém pro zápis, hrozí reálnénebezpečí poškození nebo ztráty dat, při čtení dat hrozí nebezpečí jejich podvržení.

– 36 –

5. Self Certifying File System

5.1 Úvod

Po nástupu NFS a zjištění jeho nedostatků, zejména bezpečnostních, vzniklo mnohopokusů o vylepšení a nápravu slabin NFS. Self Certifying File System je jedním z nich, jeto bezpečný globální souborový systém založený na základech NFS. Mezi přední autorypatří David Mazieres, veškeré informace o SFS včetně zdrojových souborů lze naléztna stránkách projektu [25]. Autor publikoval tento souborový systém v roce 2000 vesvé disertační práci [30] na M.I.T., předtím vydal několik odborných publikací na témabezpečnosti, decentralisovanosti a oddělení keymanagementu od souborového systému[29][28].

SFS odděluje vlastní souborový systém od keymanagementu a tvoří globální soubo-rový systém. Systém je navržen tak, aby nepotřeboval žádnou certifikační autoritu, tentodecentralisovaný návrh má za výhodu, že nikdo není zodpovědný za globální jmennýprostor a kdokoliv na Internetu si může zřídit SFS server, aniž by musel obdržet bezpeč-nostní certifikáty. Systém také není závislý na centrální certifikační autoritě, která můžebýt potenciálním středem útoku či úzkým místem systému.

SFS je rozšířeno na mnoho UNIXů jako OpenBSD, FreeBSD, NetBSD, Solaris, OSF/1a Linux (s kernelem 2.4). Autoři uvádějí, že by mělo být možné systém s minimálnímizměnami zkompilovat a spustit na libovolném operačním systému s podporou NFS verze3. Na citovaných systémech bylo SFS autory úspěšně testováno.

Krom souborových operací protokol SFS integruje též vzdálené spouštění příkazů.Uživatel může pomocí protokolu SFS na vzdáleném serveru spustit příkaz nebo získatshell.

5.2 Architektura

Architektura systému je typu klient–server, základem SFS a nutným požadavkem jeprotokol NFS verze 3 na obou komunikujících stranách. Na klientské straně stačí podporaklientu v jádře systému, na serveru je nutné spustit server a exportovat požadovanéadresáře na localhost.

5.2.1 Součásti

Jádro OS

Uživatelský programJádro OS

SFS klient

sfscd

sfsrwcd

nfsmounter

SFS Server

sfssd

sfsrwsd

sfsauthd

NFS 3server

[NFS 3]

NFS 3klient [NFS 3]

[Systémovévolání]

[Agentprotokol]

sfsagent

sfsagent

sfskey

[NFS 3 + leases]

KryptovanéTCP spojení

autentikované MAC

Obr. 4: Architektura systému SFS podle [26].

– 37 –

Uživatelský program běžící na klientu zasílá požadavky služeb souborového systémučásti NFS v jádře operačního systému, která dále komunikuje se SFS klientem běžícímv uživatelském režimu a emulujícím NFS server. SFS klient je representován daemonemsfscd, který spouští další dva daemony nfsmounter a sfsrwcd. Daemon nfsmounter

se stará o připojování a odpojování souborového systému NFS a v případě, že sfscd

zanikne, zabraňuje zablokování operací souborového systému a zajišťuje odpojení NFS.Daemon sfsrwcd pak implementuje běžné souborové operace. V případě dalšího vývojebudou nové funkce zajišťěny dalšími daemony běžícími vedle sfsrwcd.

Na serverové straně SFS server nahrazuje část NFS serveru běžící v uživatelskémmódu operačního systému a přes rozhraní NFS komunikuje s jádrem. Server, daemonsfssd, podobně jako na straně klientu po svém startu pouští další dva daemony sfsrwsd

a sfsauthd. První z daemonů je serverová obdoba sfsrwcd, která komunikuje s klientskoučástí a získává data z lokálního disku jako klient lokálně exportovaného souborovéhosystému NFS. Druhý ze zmiňovaných daemonů slouží k autentizaci uživatelů. Ze sítěpřijímá spojení od programu sfskey a umožňuje uživatelům získat jejich privátní klíčenebo změnit veřejné klíče. Dále komunikuje přímo se sfsrwsd a autentizuje uživatele dosouborového systému. Přehled architektury SFS můžeme vidět na obrázku 4.

Na klientu dále musí běžet alespoň jedna instance daemonu sfsagent, který zajiš-ťuje autentizaci uživatelů při připojování souborových systémů nových serverů a získávánová HostID. Pro správu klíčů uživatelé používají program sfskey, kterým obstarávajíklientské i serverové klíče a mohou měnit veřejné klíče na vzdálených serverech.

5.2.2 Jmenný prostor a sémantika operací

Adresářové stromy exportované servery jsou na klientu automaticky připojovány doadresáře /sfs/@Location,HostID nebo /sfs/@Location%port,HostID, kde Location

je DNS nebo IP adresa serveru, port označuje číslo TCP portu, na kterém server komu-nikuje (za výchozí port je brán TCP port číslo 4), a HostID je bezkolizní kryptografickýhash serverového veřejného klíče. Tento adresář automaticky vyrobí klient v okamžikupřipojení vzdáleného adresáře. Umístění připojeného exportovaného adresáře tedy nenízávislé na klientu, ale na serveru, proto tento zápis cesty umožňuje jednoznačnou iden-tifikaci konkrétního souboru na světě pouhým jménem. Obsah adresáře /sfs se liší prokaždého uživatele podle toho, ke kterým serverům je autentizován a připojen. Obsah ad-resáře /sfs se liší pro každého uživatele, který v něm vidí pouze servery, které si připojil.Popsaný mechanismus se nazývá self-certifying pathnames.

Nevýhoda tohoto přístupu spočívá v tom, že si uživatelé musí pamatovat HostID

příslušného serveru. Z toho důvodu systém při připojení automaticky vytvoří symbolickýodkaz na připojený adresář s názvem obsahujícím pouze adresu serveru. Při neanonym-ním přístupu je adresář v /sfs automaticky vytvořen, ale při anonymním přístupu sedaný server připojí přístupem do adresáře daného serveru, proto při anonymním pří-stupu uživatel musí do cesty zadat HostID. Pokud se změní DNS adresa serveru, souboryna všech klientech změní svoji cestu, což může mít rozsáhlé a nepříjemné následky.

Sémantika operací SFS je stejná jako u systému NFS. Objekty souborového systému,jejich atributy, operace na nich a přístupová práva tedy odpovídají UNIXovému souboro-

– 38 –

vému systému. Z důvodu bezpečnosti SFS zakazuje práci se speciálními (blokovými neboznakovými) zařízeními a nepřenáší suid bity. Jelikož každý uživatel má možnost připojitsi libovolný server na Internetu, nebylo by pro útočníka problémem vytvořit vlastní ser-ver s povoleným přístupem k systémovým speciálním zařízením nebo suid spustitelnýmsouborem s vlastníkem superuživatelem, tento server připojit a tím získat neomezenouvládu nad klientským strojem.

5.2.3 Bezpečnost a komunikace

Hlavním cílem autorů SFS bylo navrhnout silně zabezpečený souborový systém, veš-kerá komunikace SFS přes síť je vždy zabezpečená. Klient komunikuje se serverem přesprotokol TCP na portu 4, službu SFS lze tedy snadno propustit skrz firewall. Přenos pro-bíhá kryptovaným kanálem chráněným algoritmem ARC4 se 160 bitovými klíči, v každémsměru je použit jiný klíč a integrita dat je kontrolována 128 bitovým MAC založeným naSHA-1 [53]. Pracovat v režimu snížené či žádné bezpečnosti systém neumožňuje.

SFS používá několik kryptografických algoritmů. Nejužívanějším z nich je SHA-1 [53],kterým je generováno HostID. Náhodné bity generuje pseudonáhodný generátor NIST,který je rovněž založen na algoritmu SHA-1. Iniciován je z mnoha různých zdrojů —na operačních systémech, kde existuje zařízení /dev/random, z tohoto zařízení, z pseu-donáhodného systémového generátoru, z výstupu různých systémových nástrojů a přigenerování klíčů též z časových vzdáleností mezi stisky náhodných kláves uživatelem.

Při instalaci serveru administrátor vytvoří pár veřejného a privátního klíče, chce-liuživatel přistupovat k serveru, musí mít možnost nalogovat se na server a vytvořit dvojiciveřejného a privátního klíče zabezpečenou passfrází. Uživatelská hesla jsou zpracovávánaalgoritmem Eksblowfish [31], privátní uživatelské klíče jsou zpracovávány tímtéž algorit-mem a následně uloženy na disk.

Během navazování spojení si nejprve obě strany dohodnou Rabin-Williamsovým al-goritmem [32] symetrické klíče pro vytvoření bezpečného kanálu a poté, po vytvořeníkanálu, se pro samotnou autentizaci použije algoritmus SRP [27]. Minimální délka pr-vočísel použitých v SRP je 768 bitů a každý uživatel má případnou možnost zvolenívlastního prvočísla a generátoru pro protokol SRP. Protokol SRP umožňuje bezpečnouvýměnu hesel nezávisle na jejich síle a znemožňuje odposlouchání hesel i slovníkový útokpři znovu použití hesla.

Kryptování veřejných klíčů je prováděno taktéž Rabin-Williamsovým algoritmem,délka veřejného klíče je konfigurovatelná, minimální délka je 768 bitů, běžná délka 1280bitů. Výpočetní náročnost při výpočtu privátních klíčů je randomizována, aby nebylomožné zaútočit na základě časové analýzy algoritmu. NFS file–handle předávané meziklientem a serverem jsou z důvodů zvýšení bezpečnosti kryptovány algoritmem Blowfish[33] se 160 bitovými klíči v CBC módu.

SFS zajišťuje integritu dat a zároveň autentizuje server uživateli mechanismem sa-mocertifikujících se cest. Součástí cesty k souborům z daného serveru je kryptografickýhash veřejného klíče serveru HostID. Aby bylo možné se serverem komunikovat, veřejnýklíč serveru musí souhlasit s tímto hashem. Útočník tedy nemůže vydávat svůj počítač za

– 39 –

server, neboť díky neznalosti tajného klíče serveru není schopen vygenerovat shodný párklíčů a tedy se klientům bude připojovat pod jinou cestou, což uživatelé odhalí. Ve verzi0.6 systému byla součástí HostID také IP adresa serveru a protokol nebylo možné tune-lovat ani používat jako server na přenosném počítači (který má různé adresy napříkladdoma a v práci), ve verzi 0.7 byla tato nevýhoda odstraněna.

Většina systémů zajišťuje integritu nezávislou certifikační autoritou, které všichnivěří, ať už je to autorizační server, nebo hierarchický systém certifikátů. Toto centrali-sované řešení má nevýhodu, že v případě prolomení centrální autority má útočník volnýpřístup ke všem serverům, což nese fatální následky. Krom cíle útoku může být centrali-sovaný autorizační server též úzkým místem systému.

5.2.4 Bezpečnostní rizika

Bezpečnostní aspekty a možná rizika systému jsou analyzovány v dokumentaci [26].Pravděpodobně nejsnadnější způsob napadení SFS je typu DoS. Útočník může vyčerpatfile-descriptory serverového daemonu vytvořením mnoha TCP spojení. Horší problémmůže nastat, když útočník vyšle mnoho RPC žádostí, ale nepřečte si odpovědi, serverbude nucen udržovat v paměti množství dat, což může vést až k vyčerpání paměti a páduserveru. Navázání spojení stojí server desítky milisekund procesorového času, útočník tedymá možnost neúměrně zatížit procesor serverového stroje opakovaným mnohonásobnýmpřipojováním k serveru.

Naopak na klientském počítači může zaútočit uživatel, když připojí velké množstvíserverů. Jestliže operační systém má pouze omezený počet bodů pro připojování soubo-rových systémů, může dojít k jejich vyčerpání.

Dalším potenciálním rizikem je podvrhování zpráv na lokální síťové smyčce (loo-pback) na serveru nebo klientu. SFS komunikuje s NFS na lokálním počítači pomocízařízení loopback. Kdokoliv, kdo má přístup na lokální síť ethernet, na kterou je klientnebo server připojen, může generovat síťové zprávy s podvrženou IP adresou 127.0.0.1.Bez firewallu taktéž může kdokoliv zvenčí posílat síťové zprávy s podvrženou zdrojovouadresou 127.0.0.1. Tímto způsobem lze zfalšovat NFS požadavky z jádra operačního sys-tému do SFS nebo odpovědi SFS jádru operačního systému. SFS před předáním do jádraoperačního systému kryptuje file–handle identifikující objekty souborového systému, jetedy velice nepravděpodobné, že útočník zfalšuje požadavek od SFS tak, aby obsahovalplatnou file–handle. Odpověď od NFS z jádra operačního systému ovšem nemusí obsa-hovat file–handle, útočníkovi tedy stačí uhodnout 32 bitové identifikační číslo RPC XID,kterým je identifikován požadavek RPC, pokud ho útočník uhodne, může útok vyústitnapříklad v přečtení špatných dat ze souboru. Těmto útokům lze zabránit nainstalovánímvhodného paketového filtru.

– 40 –

6. NFS46.1 Úvod a historie

NFS4 bylo vydáno jako standard [4] koncem roku 2000. Samotnému vydání standardupředcházelo několik událostí, konkrétně návrh WebNFS [17][18] a specifikace protokoluGSS API [19]. V srpnu roku 1998 Sun Microsystems zahájil implementaci souborovéhosystému a v říjnu 1999 již proběhlo první testování prototypu. V únoru roku následujícíhobyl protokol podán jako návrh na standard, který vyšel koncem roku 2000 jako [4]. Navývoji se podílely firmy Sun Microsystems, Network Appliance a Hummingbird Inc.

Verze 4 protokolu NFS má stejné cíle jako předchozí verze, přímý design, snadné zota-vení z chyb a nezávislost na transportním protokolu i na operačním systému. Navíc verze4 přináší vestavěné zamykání souborů, silnou bezpečnost a slučování a delegování ope-rací. Protokol byl navrhován tak, aby zajišťoval dobrou meziplatformní interoperabilitua rozšiřitelnost.

NFS4 je navrženo jako standard k němuž existuje open source referenční implemen-tace v projektu CITI [22] na Michiganské Universitě. Tato implementace běží na systé-mech OpenBSD 3.1, Linux 2.4.18 a Linux 2.5. Ve všech případech je systém distribuovánformou patchů do zdrojových textů uvedených operačních systémů. Na operačním sys-tému OpenBSD nabízí pouze klient, na Linuxu je systém nativně integrován do jádraa nabízí klient i server, nicméně ještě je nutné aplikovat dodatečné patche.

6.2 Rozdíly od předchozích verzí

NFS4 je opět založen na mechanismu vzdáleného volání procedur [7] a opět využíváprotokolu XDR [9] pro zajištění meziplatformní přenositelnosti. Oproti předchozím ver-zím je stavový a neobsahuje žádné pomocné protokoly (mount a lock protokol). Verze 4používá jediný TCP port číslo 2039, což umožňuje snadné propuštění skrz firewall. Místopůvodního zvláštního mount protokolu se používají inicializované file–handle. Zamykáníje plně integrováno do protokolu, což jednak přináší možnost povinných zámků a paktaké díky implementaci pomocí tzv. pronajímání zámků (lease based locking) umožňujesnadné zotavení z pádů.

6.2.1 Rozdíly v sémantice

NFS4 představuje nové stavové operace OPEN a CLOSE. Tyto operace byly zavedenypro zajištění atomicity a pro podporu exkluzivního vytváření souborů. Operace OPEN

dává serveru možnost přesunout zodpovědnost na klient a tak umožnit agresivní cacheo-vání dat. Operace CREATE se používá pouze k vytváření speciálních souborů (UNIXovýchdevices), symbolických odkazů a adresářů. Procedura LOOKUP pouze nastavuje aktuálnífile–handle a nezjišťuje atributy, procedura přijímá k resoluci multikomponentální jména.Adresářová jména „.ÿ a „. .ÿ nemají speciální význam aktuálního a rodičovského adre-sáře, rodičovský adresář je nutné získat explicitním voláním LOOKUP. Operace s objektysouborového systému nevracejí informace k udržení slabé konsistence cache (atributyobjektu), namísto toho vrací strukturu change info, která obsahuje informaci, zda seadresář obsahující objekt změnil během operace.

– 41 –

Bezpečnost NFS4 zajišťuje extensibilní architektura založená na protokolu GSS API[19]. Klient zjišťuje požadovaný typ autentizace k danému souboru pomocí operace SE-

CINFO. Počáteční autentizační schemata zahrnují Kerberos [21] a LIPKEY [20]. Protokolumožňuje kontrolu přístupu k objektům podle klasického UNIXového modelu i pomocípřístupových listů ACL.

Protokol podporuje replikaci a migraci objektů, ale standard nespecifikuje detaily,jak jsou objekty přenášeny mezi servery. Atributy objektů jsou definovány obecně, jemožné je dále rozšiřovat pomocí mechanismu jmenných atributů. Protokol podporujeinternacionalisaci, jména souborů jsou kódována v UTF-8.

6.2.2 Model souborového systému

S každým souborovým systémem na serveru je spojeno jednoznačné 128 bitové identi-fikační číslo fsid. Stejně jako v předchozích verzích protokolu, server exportuje části svýchlokálních souborových systémů klientům a každý objekt souborového systému je jedno-značně identifikován file–handle. Ve verzi 4 je pohled na všechny exportované adresářejednotný, server poskytuje virtuální pseudo–filesystém, který obsahuje všechny expor-tované adresáře. Uživatel tedy nevidí, kde jsou soubory fyzicky umístěny na serveru,porovnáním fsid lze zjistit, zda dva objekty leží na serveru na stejném lokální souboro-vém systému. S příchodem jednotného pohledu na všechny exportované adresáře serveruztrácí na významu atributy jednotlivých exportů, jak tomu bylo u verzí 2 a 3 protokolu.Informace jako například velikost volného místa na lokálním souborovém systému serverujsou uloženy v atributech každého objektu.

V dřívějších verzích protokolu bylo nutné nejprve zjistit file–handle kořenového ad-resáře, než byla vůbec možná další práce se souborovým systémem. K tomu sloužilzvláštní mount protokol. Ve verzi 4 klient zjistí file–handle kořenového adresáře serve-rového pseudo–filesystému zavoláním procedury PUTROOTFH, která nastaví aktuální file–handle na kořenový adresář. Server exportuje adresáře podobným způsobem jako v před-chozích verzích. Zvolené části serverového adresářového stromu jsou uloženy do pseudo–filesystému s možností ke každému exportovanému adresáři přiřadit požadovaná bezpeč-nostní schemata.

/

vol admin backup

archivevol0 vol1 vol2

export

/

vol backup

archivevol0 vol1

Obraz souborovéhosystému serveru

Takto se jeví souborovýsystém klientům

Obr. 5: Pseudo–filesystém v NFS4.

Soubory na lokálním souborovém systému serveru jsou hierarchicky uspořádánytypicky do stromové struktury. Server exportuje většinou pouze části svého

– 42 –

adresářového stromu. Předpokládejme, že server exportuje například adresáře:

/vol/vol0

/vol/vol1

/backup/archive

U každého adresáře je možné nastavit, kde bude umístěn ve virtuálním pseudo–filesystému. Pokud adresáře netvoří strom, server vyrobí mezilehlé virtuální adresáře,aby klient mohl dosáhnout všech exportovaných adresářů z jednoho kořene. Na obrázku 5šedá plocha zobrazuje virtuální adresáře vytvořené serverem. Pseudo–filesystém obsahujepouze adresáře a je též identifikován jednoznačným fsid.

6.2.3 Skládání RPC požadavků

Procedura COMPOUND přináší zrychlení síťových operací souborového systému. V pře-chozích verzích byly operace omezené tím, že jedna operace odpovídala jednomu voláníRPC, při každé operaci bylo tedy nutné čekat na přenesení požadavku a odpovědi posíti, pokud byla odpověď použita v následujícím požadavku, data se zbytečně přenášelapo síti. Ve verzi 4 existuje operace COMPOUND, která je schopna spojit několik souvisejí-cích operací do jednoho RPC volání. Tím se sníží odezva souborového systému, což seprojeví zejména v prostředí rozhlehlých sítích. Odpověď na RPC volání pak obsahujenávratové hodnoty všech operací. Server vyhodnocuje jednotlivé operace sekvenčně a po-kud při vykonávání nastane chyba, vykonávání přeruší a volání se vrátí s toutou chybou.Vykonávání operací v proceduře COMPOUND není atomické. Většina operací v NFS vy-žaduje file–handle k identifikaci objektu, s kterým se má pracovat. V této verzi již nenínutné file–handle explicitně předávat jako argument ani ho číst jako návratovou hodnotu,namísto toho si server udržuje tzv. aktuální file–handle, kterou používá při vykonáváníprocedury COMPOUND.

Procedura LOOKUP umožňuje resoluci celé adresářové cesty v jednom okamžiku, nenítedy již zapotřebí, aby klient cestu rozdělil na jednotlivé komponenty a postupně na něvolal LOOKUP.

6.2.4 File–handle

Podobně jako v předchozích verzích, všechny objekty na souborovém systému NFS4jsou určeny jednoznačným identifikátorem file–handle. Opět dvě bitově identické file–handle ukazují na ten samý objekt. Pro zvýšení stupně optimalisace server udržuje prokaždý klient informaci o aktuální file–handle, se kterou se pracuje, není tedy nutné file–handle předávat v každém RPC požadavku, viz procedura COMPOUND. Aktuální file–handleklient může zjistit voláním GETFH, nastavit pomocí PUTFH, PUTROOTFH nebo PUTBUFH.

Existují dvě speciální file–handle: root a public, klient je může nastavit volánímiPUTROOTFH a PUTBUFH. Root file–handle odkazuje na kořenový adresář obsahující všechnyexportované adresáře serveru. Public file–handle identifikuje část serverového jmennéhoprostoru užitého WebNFS [17][18], tato file–handle může odkazovat na libovolný objektsouborového systému.

– 43 –

File–handle jsou dále rozlišovány na trvalé a dočasné. Toto rozlišení je uloženo v sa-motné file–handle a určuje ho server. Trvalá file–handle, jakmile ji klient obdrží, budevždy odkazovat na stejný objekt a v průběhu času se nebude měnit, zůstane stále stejná.V tomto smyslu byly v předchozích verzích protokolu všechny file–handle trvalé, typickybyly generovány z čísla inode, generačního čísla a čísla lokálního souborového systému.Pokud tedy například soubor byl smazán a nahrazen novým (používajícím stejný inode),stará file–handle na nový objekt již neodkazovala, byla neplatná. Na neUNIXových systé-mech často v implementacích serveru byla file–handle spojena pouze s cestou k objektu.Z toho důvodu NFS4 zavádí dočasné file–handle. Klient si u dočasné file–handle musí udr-žovat mapování mezi file–handle a cestou k objektu a pokud platnost file–handle vyprší,musí mapování zrušit. Když platnost file–handle vyprší, klient při pokusu o její použitíobdrží chybový kód NFS4ERR FHEXPIRED. Dočasná file–handle typicky vyprší, když se za-vře otevřený soubor, souborový systém odmigruje nebo, na některých systémech, kdyžklient přejmenuje soubor. Klient ovšem musí počítat s tím, že dočasná file–handle můžepřestat platit kdykoliv.

6.2.5 Delegace operací

NFS4 podobně jako předchozí verze implementuje klientskou cache, umožňuje všakserveru delegovat určité souborové operace (aktualizace souborů a zamykání) na určitoudobu klientu, aby klient mohl agresivněji cacheovat data.

Klientská cache se podobá přechozím verzím. Atributy a obsahy adresářů jsou ca-cheovány po dobu, kterou určí klient. Při prvním použití po uplynutí této doby klientzjistí od serveru, zda se objekt změnil. Při otevírání běžného souboru klient ověří platnostcacheovaných dat tohoto souboru, zjistí od serveru, zda se data změnila a na základě tétoinformace se rozhodne, zda data v cache podrží, nebo cache vyprázdní. Při zavření sou-boru klient všechna modifikovaná data zapíše na server. Pokud aplikace vyžaduje striktněsériový přístup, musí použít buďto share–reservation, nebo zamykání. Oproti předchozímverzím NFS4 definuje pravidla umožňující cacheování dat na klientech i v případě za-mčení, aniž by byla porušena integrita cache.

Pokud s nějakým objektem pracuje pouze jeden klient, server může přesunout odpo-vědnost za všechny operace OPEN, CLOSE, modifikaci dat souboru a zamykání na klient.Tím odpadá nutnost síťové komunikace při otevírání a zavírání souborů, všechny operacese zámky jsou prováděny lokálně a není nutné periodicky kontrolovat konsistenci cache,čímž se snižuje zátěž sítě a s ní související latence. Při delegování server zaručuje, že senevyskytnou žádné konkurentní operace OPEN, proto klient může data v cache považovatza platná. Je-li na serveru dostatek místa, modifikovaná data mohou zůstat na klientu i poprovedení operace CLOSE bez posílání na server, ale jen v případě, že server vyloučí pří-pad, že případné operace WRITE neuspějí pro nedostatek místa na serveru. Sdílí-li souborvíce klientů a nezapisují-li do něj, server může delegovat read–only OPEN více klientům.Tato delegace je možná pouze v případě, kdy do souboru nikdo nezapisuje, proto datav cachích klientů jsou platná, aniž by klienti museli platnost ověřovat.

Delegování operací je platné pouze určitou dobu označovanou jako lease, po uplynutítéto doby je delegace zrušena, stejně jako zámek, a klient musí o delegaci znovu žádat.

– 44 –

Delegace operací zvyšuje efektivitu častého zamykání, sdílení dat pro čtení a částečněi sdílení pro zápis (pokud sdílení probíhá pouze na jednom klientu), bez nutnosti přílišnékomunikace se serverem.

Při odvolání delegovaných operací je nutné, aby klient obnovil stav souboru na serverutak, aby soubor na serveru obsahoval změny provedené klientem. Delegování ukončuje ser-ver mechanismem zvaným callback, jedná se o RPC volání ze serveru na klient. Pokudnapříklad klient B požádá o přístup k souboru, který je delegován jinému klientu A prozápis, server delegaci klientu A zruší zavolání callbacku, klient A data vrátí na servera klient B může provést požadovanou operaci. Volání callback musí být kleintu doruči-telné, případný firewall by mohl zamezit volání callback ze serveru na klient. Pokud klientpožádá server o delegaci, server nejprve otestuje, zda je klient schopen odpovídat na call-back, a pokud ano, delegaci je možno provést. V opačném případě se delegace neprovedea příslušné operace se souborem budou méně efektivní.

6.2.6 Zamykání

NFS4 již obsahuje mechanismus zamykání v samotném protokolu, princip je podobnýdodatečnému zamykacímu protokolu k verzím 2 a 3. Od předchozích verzí se liší zejménaprincipem leases a implementací povinných zámků. Povinné zámky jsou klíčovým mecha-nismem v operačních systémech Windows, pokud je na souboru povinný zámek, operacejiných procesů na daném souboru jsou zablokovány, dokud vlastník zámku zámek neo-demkne. Ve verzích 2 a 3 protokolu byly implementovány pouze zámky nepovinné, kterélze použít pouze u spolupracujících procesů.

Hlavní problémem zamykacího protokolu v předchozích verzích byl předpoklad, žetransportní protokol je spolehlivý a doručí síťové zprávy ve stejném pořadí, v jakém bylyodeslány. S nespolehlivou sítí se snadno mohlo stát, že zámek zůstal navždy zamčen. Veverzi 4 server zámky „půjčujeÿ jen na určitou dobu, na dobu tzv. lease. Stejný princip sepoužívá u delegovaných operací. Během této vyhrazené doby server neposkytne přístupk souboru jinému klientu, po vypršení lease server očekává, že klient znovu pošle požada-vek k zamčení souboru. Jestliže klient nebo spojení mezi klientem a serverem havaruje,server po uplynutí lease zámek uvolní. Po pádu serveru a jeho opětovném zotavení ser-ver počká dobu, kterou trvá lease, zda klienti obnoví své zámky, a teprve pak akceptujenové požadavky na zamčení. Doba pronajímání zámků je podstatně delší než doba, nakterou jsou delegovány operace, neboť při delegování operací není žádoucí zdržení běž-ných souborových operací. Pokud je klientu A delegována operace se souborem a klientB chce k tomuto souboru přistoupit, tak by musel čekat, než vyprší dotyčná doba lease,při pokusu o zamčení souboru jiným klientem delší doba čekání nevadí. Prodlouženímdoby propůjčení zámku se sníží zátěž sítě. Klient občerstvuje všechny zámky najednou,občerstvení jednoho zámku způsobí automatické občerstvení všech ostatních zámků, tímse opět sníží potřeba síťové komunikace, která je jedinou nevýhodou mechanismu pronají-mání zámků. Princip leases je používán i v jiných distribuovaných souborových systémech[16][23][24].

Každý klient po prvním připojení k serveru odešle strukturu jednoznačně identifiku-jící klient a jednoznačný verifier, což je unikátní neopakující se 64 bitové číslo genero-

– 45 –

vané klientem, které pomáhá serveru detekovat reboot klientu. Jakmile server obdrží tytoúdaje, vrátí klientu 64 bitový unikátní clientID, který nekoliduje s dříve poskytnutýmiclientID ani v případě restartu serveru. Klient v požadavku o zamčení souboru odešlesvůj clientID a jednoznačný identifikátor uživatele v rámci klientu lock owner, jehožgenerování je záležitost každého klientu, typicky jím bývá identifikátor procesu, vláknaa podobně. Akceptuje-li server zámek, vrátí 64 bitový stateID, který slouží k identifikacivlastníka zámku, server musí být schopen poznat neplatný nebo starý stateID, včetněstateID vygenerovaných předchozími instancemi serveru. Pomocí clientID se klient ser-veru identifikuje, tento identifikátor ale slouží i k obnovení stavu zámků při pádu klientunebo serveru. Server po restartu odmítá požadavky klientu obsahující staré clientID,čímž donutí klient znovu požádat o clientD a obnovit veškeré zámky. Dojde-li k páduklientu, klient musí kontaktovat server, aby obdržel své clientID, při čemž server dete-kuje reboot klientu, neboť se změnil verifier klientu, a uvolní všechny zámky drženétímto klientem.

NFS4 krom zámků poskytuje ještě tzv. share–reservation, což je mechanismus umož-ňující procesu otevřít soubor a současně ostatním procesům otevření pro čtení nebo zápiszakázat. Mechanismus je podobný povinným zámkům, liší se pouze tím, že funguje nacelý soubor a zaniká se zavřením souboru. Proces například může otevřít soubor pročtení a ostatním procesům zakázat zápis do souboru. Mechanismus share–reservation jeznám z operačních systémů Windows, pro správnou sémantiku share–reservation sys-témy Windows vyžadují od souborového systému možnost atomického vytvoření souborua současného požádání o share–reservation. NFS4 z tohoto důvodu poskytuje operaciOPEN, která atomicky provede vyhledání cesty v adresářové struktuře, vytvoření, požá-dání o share-reservation a vrácení file–handle souboru.

Při vyřizování požadavků na zamykání je velice důležité, aby požadavky byly uspořá-dané. Tedy když například klient pošle požadavek na zamčení, odemčení a znovuzamčenía poté požadavek na odemčení bude vinou sítě zduplikován, aby nedošlo k opětovnémuodemčení souboru, které by způsobilo poškození dat. Tomuto případu se snaží zabránitvrstva RPC tím, že čísluje jednotlivé požadavky. Server ovšem nemá dostatečně vel-kou paměť na všechny požadavky v historii, tedy se nemůže vyvarovat všech případů.Proto klient přiřazuje ke každé operaci pracující se zámkem sekvenční číslo identifikujícíoperaci, identifikační čísla tvoří ascendentní posloupnost s diferencí 1. Server si ke kaž-dému klientu pamatuje poslední sekvenční číslo a poslanou odpověď. Pokud znovu přijdepožadavek s tímto číslem, klient neobdržel odpověď od serveru a server tedy odpověďzopakuje. Jestliže však přijde požadavek s číslem nižším než poslední (starší požadavekbyl vinou sítě duplikován), nebo vyšším než poslední číslo zvýšené o jedničku, požadavekje odmítnut a volání skončí s chybou.

6.2.7 Atributy objektů

NFS4 přichází s kompletně odlišným systémem souborových atributů. Mechanismusje velice dobrý, jeho autoři se zaměřili zejména na univerzálnost, přenositelnost a případ-nou další rozšiřitelnost. Atributy se dělí na tři typy: povinné (mandatory), doporučené(recommended) a pojmenované (named).

– 46 –

Jelikož se ke všem exportovaným adresářům serveru přistupuje jednotně z jednohoadresářového stromu, atributy příslušící jednotlivým lokálním souborovým systémům ne-zjišťují zvláštními voláními (například velikost volného místa na souborovém systému),ale jsou zahrnuty jako součást atributů objektů.

Povinné atributy representují nejzákladnější atributy, které musí být podporoványnebo emulovány všemi implementacemi souborového systému. Patří mezi ně:

� typ objektu — zda se jedná o soubor, adresář, speciální soubor, . . .

� velikost

� fsid — identifikátor souborového systému na serveru, kde je objekt uložen

� doba trvání lease v sekundách

� podpora UNIXových linků — zda hostitelský souborový systém, na kterém jeobjekt uložen, podporuje UNIXové linky

� podpora UNIXových symlinků — zda hostitelský souborový systém, na kterém jeobjekt uložen, podporuje UNIXové symbolické linky

� indikátor změny — hodnota, podle které klient může zjistit (porovnáním s dřívezískanou hodnotou), zda došlo ke změně objektu (souboru, adresáře)

� způsob expirace file–handle — zda se jedná o trvalou nebo dočasnou file–handle,zda může dojít k vypršení file–handle díky migraci, atd.

Doporučené atributy, jak již sám název napovídá, nemusí být přítomny ve všechimplementacích. Klient musí být schopen se vyrovnat se situací, kdy některý z atributůnení na daném serveru k dispozici. Standard tyto atributy pouze doporučuje, tedy nasystémech, na kterých jsou dostupné, je server poskytne a pokud by atributy měly „říkatlžiÿ, server je neposkytne. Jako příklad může sloužit čas modifikace souboru, který můžebýt buďto přesný čas, nebo ho server neposkytuje. Bitové pole obsahující informaci, kteréatributy server poskytuje, klient zjistí od serveru.

Mezi doporučené atributy patří:

� ACL — access list

� bit archive — odpovídá MS-DOSu

� case insensitive — rozlišuje se v názvu mezi velkými a malými písmeny?

� case preserving — zachovávají se velká a malá písmena v názvech?

� hidden bit — odpovídá MS-DOSu

� file ID — identifikátor souboru

� file–handle

� maximální velikost souboru

� maximální počet linků na objekt

� maximální délka jména

� MIME typ

� UNIXová přístupová práva

– 47 –

� řetězec se jménem vlastníka

� řetězec se jménem skupiny

� čas poslední modifikace

� čas vytvoření

� čas posledního přístupu

� velikost volného místa na souborovém systému

� celková kapacita souborového systému

� místo volné pro uživatele

� místo obsazené objektem

� maximální možná velikost čtených dat

� maximální možná velikost zapisovaných dat

S každým objektem je asociován skrytý virtuální adresář obsahující všechny jmennéatributy. V tomto virtuálním adresáři každému jmennému atributu odpovídá jeden sou-bor, jehož obsah je hodnotou atributu. Hodnota je v NFS4 neinterpretovaná, považuje sepouze za tok bytů. Interpretace záleží na klientu. Jmenné atributy musí být podporoványserverem. K atributům se přistupuje procedurou OPENATTR, která vrátí file–handle virtu-álního adresáře s atributy, a poté se běžnými procedurami READDIR a LOOKUP adresář čtea procedurami READ, WRITE a CREAT se hodnota čte, modifikuje a vytváří se nové atributy.Mechanismus jmenných atributů je běžný v některých lokálních souborových systémech,například ve Windows NTFS. Ve jmenných atributech lze ukládat další atributy, kterév návrhu NFS4 nebyly zahrnuty.

Návrh souborového systému umožňuje použití access listů. ACL patří mezi doporu-čené atributy, nejsou tedy povinné a ne každý server je musí podporovat. ACL v NFS4jsou navrženy podle modelu Windows NT, ne podle POSIXového modelu, neboť modelWindows NT je bohatší a rozšiřitelnější.

6.3 Bezpečnostní model

Uživatelé a skupiny již nejsou representovány pomocí 32 bitových integerů, jak tomubylo v NFS dosud, ale pomocí řetězců tvaru: user@domain nebo group@domain, kde do-

main je registrovaná DNS doména. Jelikož některé operační systémy (zejména systémyUNIX) používají na lokálním souborovém systému číselné identifikátory uživatelů a sku-pin, na těchto systémech klient nebo server musí zajistit příslušné mapování. V NFS4tedy již není nutné synchronisovat databáze uživatelů na klientech a serverech.

Veškerá bezpečnost NFS4 závisí na bezpečnosti RPC komunikace. Již v dřívějšíchverzích existovalo několik typů bezpečnosti, ale ty jednak nebyly dostatečně bezpečnéa hlavně při použití v praxi nebyly povinné. Ve verzi 4 je povinná implementace bezpeč-nostního protokolu založeném na Generic Security Services API, který se nazývá RPC-SEC GSS [19]. RPCSEC GSS zahrnuje autentizaci, kontrolu integrity a kryptování RPCpožadavku. Z bezpečnostních mechanismů GSS-API standard udává povinnost imple-mentovat alespoň Kerberos verze 5 [21] a LIPKEY [20].

– 48 –

Kerberos najde své využití zejména v intranetu, kdežto pro aplikace na Internetuse více hodí schema LIPKEY, neboť pro použití systému Kerberos by díky jeho návrhubylo zapotřebí spolupráce lokálního administrátora a administrátora vzdálené Kerberosrealm. SSL nebylo použito z toho důvodu, že nemůže být provozováno nad nespolehlivýmprotokolem UDP, kdežto NFS4 nad tímto protokolem pracovat může.

Verze 2 NFS neobsahovala žádný mechanismus pro vyjednávání bezpečnostního pro-tokolu, pokud server exportoval adresář s autentizačním mechanismem odlišným odAUTH SYS, nemohl tuto informaci klientu sdělit. Verze 3 mount protokolu toto již umož-ňovala, ale samotný mount protokol nebyl bezpečný. Ve verzi 4 se použitý bezpečnostnímechanismus vyjednává speciální operací SECINFO.

6.4 Replikace a migrace dat

Souborový systém podporuje replikaci a migraci dat mezi servery. Tato vlastnostnení povinná a opět záleží na implementaci serveru, zda bude podporována, či nikoliv.Nenacházejí-li se data na serveru z důvodu odmigrování, klient je upozorněn speciálnímchybovým kódem NFS4ERR MOVED, tuto chybu vrátí všechny operace krom GETATTR. Novéumístění objektu lze zjistit z atributů fs locations, klient se poté transparentně můžeobrátit na nový server, aniž by se aplikace dozvěděla o migraci dat. Je-li souborovýsystém exportován pouze pro čtení, lze data též replikovat. V takovém případě atributfs locations slouží k určení alternativních umístění souborového systému. Neodpovídá-li například server nebo odpovídá-li pomalu, klient může zvolit jiný server, na kterém jesouborový systém s objektem umístěn. Atribut fs locations obsahuje seznam IP neboDNS adres serveru a příslušnou cestu ke kořeni exportovaného souborového systému,na kterém se objekt nachází. Při přechodu na nový server klient musí znovu vyžádatfile–handle daného objektu.

Standard nespecifikuje, jakým způsobem budou data mezi servery replikována nebopřemisťována, popisuje pouze způsob, jakým klient komunikuje se serverem v případě mi-grace dat. Návrh migračního a replikačního protokolu proto závisí na konkrétním výrobci.Z toho důvodu bohužel hrozí nebezpečí vzniku nekompatibilních protokolů.

– 49 –

7. SMB/CIFS, Samba

7.1 Úvod a historie

SMB (Server Message Block) je protokol pro sdílení tiskáren, souborů, sériových portůa komunikačních abstraktů (například pojmenovaných rour) mezi počítači. S protokolempřišla v roce 1984 firma IBM, vývoj následně v roce 1986 převzaly firmy Microsoft a IN-TEL, poté protokol vyvíjela už jen firma Microsoft.

V produktech Microsoftu se SMB stal rodným protokolem pro sdílení souborů a tiská-ren, počínaje operačním systémem DOS a pokračuje systémy Windows. Microsoft nebylajediná firma užívající tento protokol, existuje mnoho dalších implementací v systémechjako například DEC Pathworks, IBM OS/2, LAN Manager na SCO a HP-UX, AT&TAdvanced Server a dalších. IBM dalo protokolu základ, tzv. SMB Core Protocol [44], kterýMicrosoft postupně rozvíjel až do dnešní podoby, do protokolu CIFS (Common InternetFile System). Názvem SMB jsou označovány verze protokolu před vydáním WindowsNT4, CIFS označuje verze z Windows NT4 a další. Všechny verze jsou navzájem zpětněkompatibilní, takže CIFS je pouze nadmnožinou SMB Core Protokolu. Přehled verzí lzenalézt v [39]. Protokol SMB byl oficiálně standardisován Microsoftem a X/Open (OpenGroup) ve specifikacích [45] a [46]. Microsoft v roce 1997 vydal specifikace protokolu veformě internetových draftů, jejichž platnost po půl roce vypršela, ale později již žádnédalší dokumentace nezveřejnil. Proto pod vedením Storage Network Industry Association(SNIA) vznikla „otevřenáÿ specifikace protokolu CIFS [48]. V textu se zaměříme zejménana verzi protokolu „NT LM 0.12ÿ a „CIFS 1.0ÿ, jak je popsán v [39] a [48].

Díky zveřejnění specifikací CIFS jako RFC bylo možné, aby na australské ANU (Aus-tralian National University) v roce 1991 vznikly základy open–source implementace dnesznámé pod názvem Samba. Hlavním autorem se stal Andrew Tridgell, vývoj byl od za-čátku sponzorován universitou. Samba je šířena v podobě zdrojových textů pod licencíGNU General Public License (GPL), může běžet na systému OpenVMS a mnoha vari-antách UNIXu a tak umožňuje propojení světa UNIXu se světem Windows.

Vedle Samby vzniklo ještě několik dalších open–source projektů implementujícíchprotokol SMB, mezi ně můžeme zařadit porty Samby na platformy Amiga, VMS a další,alternativní větev Samby Samba-TNG nebo Java implementaci jCIFS. Z komerčníchprojektů můžeme zmínit DAVE na platformě Macintosh, Sharity, SCO VisionFS, QNXklient a server, IBM LAN Client 2.x, LAN Server a LAN Manager, TotalNET AdvancedServer od firmy Syntax, Advanced Server for UNIX od AT&T.

Protokol byl navrhován s cíli efektivnosti, zejména na pomalých linkách, škálovatel-nosti, odolnosti proti chybám, rozšiřitelnosti, dobré administratelnosti a použití v inter-nacionálním prostředí.

7.2 Komunikace

Protokol CIFS je typu klient–server a request–response. Server nabízí své souborya sdílené prostředky klientům. Rozdělení nemusí být striktní, počítač může být současněklientem i serverem, což je v sítích Windows typická situace.

– 50 –

V ISO/OSI modelu protokol najde umístění na aplikační a presentační vrstvě. Pro-tokol SMB byl navržen pro provoz nad relačním protokolem NetBIOS [38]. NetBIOSnení routovatelný protokol, proto se jako transportní protokol nepoužívá a na transportnívrstvě ISO/OSI modelu se používají jiné, routovatelné, protokoly, zejména TCP/IP. Jakotransportní protokol lze tedy užít TCP/IP, IPX/SPX, NetBEUI, případně další, jako na-příklad DECnet [36] 2). Specifikace [39] též popisuje provoz CIFS přímo nad TCP/IP,provoz se odehrává na TCP portu číslo 445. V reálném nasazení je v sítích TCP/IP nej-používanější transportní protokol NetBIOS over TCP/IP, kde je použito UDP portů 137a 138 a TCP portu 139. Protokol je též znám pod názvem NBT a je definován v [34]a [37]. CIFS nestandardisuje žádný konkrétní transportní protokol, vyžaduje pouze spo-jovaný protokol zaručující doručení dat, nevyžaduje zachování pořadí odeslaných zpráv.Dalším požadavkem je dobře známý komunikační koncový bod, například dobře známýport, a konečně mechanismus zaručující detekci pádu klientu nebo serveru a doručení tétoinformace druhé komunikující straně. Zařazení do ISO/OSI modelu znázorňuje následujícíobrázek:

Aplikační

Presentační

Relační

Transportní

Síťová

Linková

ISO/OSI

Aplikační

TCP/UDP

IP

Linková

SMB

NetBIOS NetBIOS NetBIOS

TCP+UDP

IPIPX DECnet

NetBEUI

802.2,802.3, 802.5

802.2,802.3, 802.5 Ethernet V2 Ethernet V2

TCP/IP

Fyzická

Obr. 6: Zařazení SMB protokolu do hierarchie ISO/OSI.

Protokol CIFS je založen podobně jako NFS na mechanismu vzdáleného volání funkcí.Nikoliv však podle standardů od Sun Microsystems [5][6][7], ale podle specifikace OpenGroup [47]. Model vzdáleného volání je stejný jako u NFS, ale protokol je odlišný. [47] de-finuje více abstraktních vrstev, obsahuje již specifikaci jednotného formátu dat, popisujevytváření universálních jednotných identifikátorů UUID, specifikuje bezpečnostní modela přesně definuje implementaci na spojovaných i nespojovaných transportních protoko-lech. Celá specifikace [47] má za úkol převést volání RPC na bytové toky, které vrstvyklientského a serverového RPC runtime předávají nižším transportním vrstvám.

Komunikace tedy fakticky probíhá formou výměny zpráv, ve kterých může být obsa-žen buďto požadavek klientu, nebo odpověď serveru. Některé zprávy mohou být sesku-povány dohromady a poslány najednou, aby se snížila latence odpovědi a zátěž na síti.Zpráva obsahuje identifikátor protokolu, kód příkazu, kód chyby, jednoznačný identifiká-tor sdíleného prostředku, jednoznačný identifikátor uživatele a samotných dat. Zprávylze rozdělit do tří skupin:

2) Z citovaných transportních protokolů bylo testováno pouze TCP/IP.

– 51 –

� zprávy řízení relace pro navazování a zavírání NetBIOS spojení se serverem

� zprávy přístupu k souborům pro veškerou práci se soubory a adresáři

� obecné zprávy, pro posílání dat do tiskových front, mailových slotů a pojmeno-vaných rour

Komunikace mezi klientem a serverem vypadá následovně: Klient se serverem vytvoříNetBIOS relaci, domluví se na verzi protokolu, nástaví parametry relace, klient se zalogujena server, připojí se ke sdílenému prostředku a pracuje s ním.

1. Na začátku komunikace klient požádá server o vytvoření NetBIOS relace. Klientvyšle ve zprávě netbios session request svoje NetBIOS jméno SMB serveru,který poslouchá na TCP portu číslo 139. Server odpoví zprávou netbios session

granted s potvrzením vytvoření relace. NetBIOS relace tvoří obousměrný virtuálníkanál mezi klientem a serverem.

2. Klient vyšle zprávu vyjednávání verze protokolu SMB negprot request. Součástízprávy je seznam klientem podporovaných verzí protokolu, z které server vyberenejvyšší verzi, kterou umí komunikovat. Pokud server nebo klient podporuje něja-kou verzi protokolu, musí též podporovat všechny verze nižší, až do Core Protocolu.V odpovědi SMB negprot reply server uvede též další informace jako jméno SMBdomény, maximální akceptovaný počet spojení k serveru a další.

3. Následuje nastavení parametrů relace a přihlášení. Klient odešle zprávu SMB sess-

setupX request, která obsahuje uživatelské jméno, heslo (nebo jen heslo, závisí natypu autentizace), jméno pracovní skupiny a další parametry, na což server v pří-padě úspěšné autentizace odpoví zprávou SMB sesssetupX reply s uživatelskýmčíslem UID, kterým pak klient dále identifikuje tohoto uživatele.

4. Nakonec klient žádá zprávou SMB tconX request o přístup ke sdílenému pro-středku, který v tomto případě identifikuje síťovým jménem. Server opět ověřípřístupová práva uživatele a v případě úspěchu vrátí ve zprávě SMB tconX reply

16 bitové TID (tree ID) identifikující onen sdílený prostředek.

5. Nyní klient může přistupovat k objektům sdíleného prostředku, klient odešle cestuk objektu a server (opět po úspěšném ověření přístupových práv) vrátí ID objektu,pomocí něhož se klient na objekt může v dalších požadavcích odkazovat.

Objekty na sdíleném prostředku jsou identifikovány pomocí 16 bitových identifikátorůFID, které spolu s 16 bitovým TID identifikujícím sdílený prostředek jednoznačně popisujíobjekt na serveru. FID má stejný význam jako file–handle v NFS. Užití pouhých 16 bitůk ukládání FID má za následek omezení maximálně 65536 otevřených souborů jednímuživatelem na daném serveru. Naplnění této meze při běžném užívání prakticky nehrozí,ale ve výjimečných případech by mohlo nastat a vadit při práci se souborovým systémem.

7.2.1 Řetězení zpráv

Pro zvýšení výkonu, snížení latence odesílaných požadavků a snížení síťové zátěže pro-tokol umožňuje řetězit RPC volání za sebe do jedné odesílané zprávy. Řetězení se provádípoužitím tzv. AndX volání (názvy těchto volání končí „AND Xÿ). Většinu požadavků lze

– 52 –

řetězit, ale ne všechny. Zřetězené požadavky musí spolu souviset.

Klient do zprávy serveru uloží na začátku hlavičku, za kterou následuje AndX po-žadavek, který krom parametrů obsahuje ještě offset určující pozici dalšího požadavkuve zprávě. Další požadavek může být též typu AndX a takto lze pokračovat až do zapl-nění maximální velikosti zprávy. Poslední požadavek ve zprávě má na místě offsetu nulu.Zpráva tedy připomíná spojový seznam. Řetězení může požadavky poněkud omezit, na-příklad řetěz SMB COM TREE CONNECT AND X, SMB COM OPEN AND X a SMB COM WRITE dovo-luje menší velikost zapisovaných dat než by mohlo být zapsáno samotným SMB COM WRITE.

Server požadavky zpracovává sekvenčně v pořadí uvedeném ve zprávě. Výsledky zís-kané z předchozího zpracovaného požadavku jako například TID nebo FID jsou použitypři zpracovávání požadavku dalšího. Všechny řetězené požadavky musí pracovat se stej-ným sdíleným prostředkem (TID) a stejným objektem (FID). Odpověď na řetězený po-žadavek je poslána pouze jedna s výsledkem posledního vykonaného požadavku. Pokudběhem vykonávání nastane chyba, vykonávání se přeruší, server odešle odpověď a zbylépožadavky zůstanou nevykonány, sémantika v případě chyby odpovídá odesílání jednotli-vých zpráv, tedy například pokud klient odešle SMB COM OPEN AND X a SMB COM READ a přičtení dojde k chybě, soubor zůstane otevřen.

7.2.2 Další služby protokolu SMB

Protokol SMB nabízí krom služeb souborového systému též další služby jako tiskna vzdálené tiskárně [42] nebo prohlížení síťového okolí [40]. Zahrnuje též další pod-protokol RAP (Remote Administration Protocol) [43], který umožňuje získání informacío uživateli, změnu uživatelského hesla, zalogování uživatele, získání informací o sdílenémprostředku, serveru, získání přehledu všech sdílených prostředků na serveru, přehleduserverů v doméně. Tyto služby a subprotokoly však nespadají do náplně této práce.

7.3 Model souborového systému

Služby, které CIFS server nabízí, se nazývají share. Share může být adresářový strom,tiskárna, sériový port nebo pojmenovaná roura. Share jsou na serveru umístěny paralelně,nejsou nijak uspořádány například do stromové struktury jako v NFS4 nebo SFS. Každýshare může mít nastavena jiná přístupová práva, jiný bezpečnostní model, může povolo-vat přístup jiným uživatelům. Přistupuje-li klient k serveru, musí uvést konkrétní share,seznam všech share lze anonymně získat od serveru.

Servery a share se adresují pomocí tzv. UNC — universal naming convention.Formát je následující:

\\<server-name>\<share>\<path>

Kde <server-name> je adresa serveru, <share> je název share, za kterým případněještě následuje cesta <path> k objektu (například k souboru).

7.3.1 Adresace

Adresa serveru může být udána jako IP adresa, DNS adresa, nejčastěji NetBIOSjméno, nebo v některých připadech kombinace NetBIOS jména a doménové adresy. V prv-

– 53 –

ním případě je vyhledání serveru triviální, v druhém případě se doménová adresa přeložína IP adresu s použitím mechanismu DNS překladu.

NetBIOS adresy jsou jednoúrovňové, jmenné, maximálně 16 znaků dlouhé. Samotnéjméno počítače je uloženo v prvních patnácti znacích, všechna písmena musí být velká,pokud je název kratší, je doplněno mezerami na požadovanou délku. Poslední znak máspeciální význam — typ počítače, například 0x00 označuje pracovní stanici, 0x20 servernabízející sdílené prostředky, atd. Adresa musí být jednoznačná v rámci celé NetBIOSsítě, typicky se jako adresa uvádí jméno serveru v DNS doméně. Překlad z NetBIOSadres na IP adresy lze provádět čtyřmi způsoby [34][37]. Nejjednodušší způsob je zjiš-tění adresy vysláním broadcastu, uzly, které se takto chovají, se nazývají B-uzly. Dalšízpůsob překladu, který provádějí tzv. P-uzly, je kontaktováním NetBIOS jmenného ser-veru, tzv. NBNS, v sítích Microsoft se tento server nazývá WINS server. Po spuštěnítedy SMB server nejprve zaregistruje svoji IP adresu a NetBIOS jméno u NBNS a potéklienti získávají IP adresu SMB serveru od NBNS. Uzly NetBIOS sítě, které se pokusízískat adresu nejprve pomocí broadcast vysílání a v případě neúspěchu kontaktují NBNSserver, se v sítích nazývají M-uzly. Poslední možností, jak přeložit NetBIOS adresu, jenejprve kontaktovat NBNS server a pokud není dostupný, získat překlad broadcastem,tento postup používají H-uzly. V sítích SMB jsou všechny uzly typu H, a pokud nenínakonfigurován WINS server, chovají se jako uzly B.

Zajímavá myšlenka je integrace WINS do DNS. WINS server v doméně překládáNetBIOS adresy, příslušný DNS server je nakonfigurován tak, aby v případě neznáméhojména počítače kontaktoval WINS server, ten pak provede překlad a vrátí adresu DNSserveru, který ji předá tazateli. Pokud tedy například v doméně cybernet.cz existujeSMB server s NetBIOS jménem shunka, který nemá DNS záznam, klient přesto můževyžádat překlad adresy shunka.cybernet.cz. Kontaktuje doménový server pro doménucybernet.cz, ten zjistí, že záznam pro stroj shunka neexistuje, proto požádá WINSserver o překlad. WINS server provede překlad, vrátí adresu DNS serveru a ten ji předáklientu, který ani nemusí vědět, že jméno shunka není DNS jméno, ale NetBIOS jméno.

7.3.2 Jmenný prostor

Jména souborů ve starších verzích protokolu musela být omezena konvencí 8.3, jakje známa například z operačního systému MS-DOS. Jméno se skládá ze dvou částí:8 znakového jména a 3 znakové přípony, části jsou od sebe odděleny tečkou. Od verzeprotokolu „LM 2.0ÿ je pak délka omezena na maximálně 255 znaků podobně jako v sys-témech UNIX nebo Windows NT. Klient určí v hlavičce SMB zprávy, zda je omezenkonvencí 8.3, a server podle toho nakládá se jmény souborů. SMB respektuje dvě spe-ciální komponenty adresářové cesty, kterými jsou „.ÿ a „. .ÿ. Význam je stejný jako navětšině souborových systémůi, „.ÿ odkazuje na aktuální adresář, „. .ÿ na adresář o jednuúroveň výše. Jednotlivé komponenty adresářových cest se oddělují znakem zpětné lo-mítko, pokud je na klientu zvykem oddělovat komponenty jinak, klient musí oddělovacíznaky přeložit.

Rozdílné pojmenovávání objektů souborového systému mezi jednotlivými verzemipřináší problémy s překladem dlouhých jmen na jména 8.3. Problémy nejsou jen v délkách

– 54 –

jmen, ale i v rozlišování velkých a malých písmen. UNIXové servery Samba velikostpísmen rozlišují, systémy Windows ne, pouze při vytváření souborů. Překlad jmen provádíserver a záleží na implementaci, jaký mechanismus bude použit. V zásadě lze použít dvapřístupy mapování [55]. V prvním případě na hostitelském souborovém systému existujetzv. shadow file obsahující mapování, tento soubor může být buďto jeden pro celý server,jeden pro share, nebo jeden pro každý adresář. Druhý způsob spočívá v překladu jmenza běhu, což se nejčastěji provádí technikou tzv. name mangling. Jméno, které se nevejdedo schematu 8.3, se přeloží tak, že se ze jména vezme několik prvních znaků (typickypět), doplní se speciálním znakem, který ve jménech objektů nesmí být použit (typickyvlnovka „�ÿ), a do zbylých znaků a přípony se uloží hash zbytku původního jména.Začátek jména se ponechává stejný, aby pro uživatele bylo snadné a intuitivní nalezenísouboru. Hashovací funkce by měla vytvářet pokud možno co nejméně kolizí. Podrobnýpopis funkce v systému Samba lze nalézt v [35] v kapitole 5.4.

Jméno v SMB požadavcích nemusí striktně odkazovat na jeden objekt v share, alemůže odkazovat na množinu objektů, použije-li se mechanismus tzv. wildcards (známýnapříklad z operačního systému MS-DOS). Tento mechanismus umožňuje pracovat s vícesoubory v jednom požadavku, aniž by bylo nutno soubory vyjmenovávat separátně. Jdeo použití speciálních znaků „*ÿ a „?ÿ ve jménech souborů, princip je podobný regulárnímvýrazům. Znak hvězdička „*ÿ v tomto případě zastupuje 0 a více znaků, znak otazník„?ÿ zastupuje jeden libovolný znak. Ve jménech typu 8.3 se každá část (jméno a přípona)posuzují zvlášť. Část před tečkou ve wildcardu se tedy porovnává se jmennou částí názvua část za tečkou se porovnává s příponou názvu. V dlouhých názvech souborů se wildcardna části nerozděluje a bere se jako celek.

Řetězce mohou být kódovány buďto v ANSI, nebo v Unicode [56]. Podpora Unicodebyla zavedena ve verzi protokolu „NT LM 0.12ÿ. Zda bude Unicode kódování znakůpoužito, vyjednává klient se serverem během navazování komunikace. Servery, které ne-podporují Unicode na svém hostitelském souborovém systému, musí jména překládatpomocí překladových tabulek nakonfigurovaných v serveru.

7.3.3 Souborový systém

SMB si díky své historii a počátcích v době MS-DOSu nese jistá omezení nebo odliš-nosti od dnes běžných souborových systémů. Tyto odlišnosti mohou tvořit problémy přiimplementaci souborového systému.

Prvním problémem může být kódování času a data u souborů. Datum a čas v pro-tokolu může být kódován třemi možnými způsoby. První způsob vychází z operačníhosystému MS-DOS, datum je kódováno ve struktuře SMB DATE, která obsahuje 3 položky:Day, Month a Year. První dvě určují den a měsíc v roce, a mohou nabývat hodnot 1–31a 1–12, poslední, která může nabývat hodnot 0–119, representuje rok v rozmezí 1980–2099. Čas je ukládán ve struktuře SMB TIME, která obsahuje hodiny Hours v rozsahu0–23, minuty Minutes v rozsahu 0–59 a sekundy TwoSeconds s granularitou 2 sekundyv rozsahu 0–29. Tato representace je použita ve standardních voláních pro zjišťováníinformací o objektu souborového systému. Další možná representace se zakládá na zvyk-lostech operačního systému Windows NT, kde je datum i čas representován v 64 bitovém

– 55 –

znaménkovém integeru vyjadřujícím buďto absolutní čas, nebo časový interval (zápornéhodnoty). Jednotky jsou 100ns od počátku roku 1601 A.D. dle Gregoriánského kalendářeUTC. Tento formát času se používá v rozšířených voláních NT, která pracují se souborystejným způsobem jako operační systémy Windows NT a které jsou dostupné od verzeprotokolu „LM NT 0.12ÿ. Konečně třetí používaný formát známý z UNIXového světaukládá čas v 32 bitovém neznaménkovém integeru v sekundách od počátku roku 1970UTC, formát se používá k uložení času poslední modifikace souboru při zavření a přivytváření dočasných souborů. SMB tedy umožňuje representovat čas ve formátech sys-témů MS-DOS, Windows NT i UNIX, ale každá representace je použita pro jiná volání.Proto klient musí zajistit převod jednotlivých formátů na domovský formát používanýoperačním systémem klientu.

Souborové atributy jsou rovněž několika druhů. V Core Protokolu objekty mohly mítpouze atributy operačního systému MS-DOS, které jsou representovány bitovou mapoupříznaků read–only (pouze pro čtení), hidden (skrytý objekt, pokud není v operačnímsystému explicitně nastaveno zobrazování skrytých objektů), system (systémový soubor),volume, archive (soubor byl změněn od poslední archivace) a directory (jedná se o adresář).Representace těchto atributů je na UNIXových systémech problematická, neboť UNIXovéatributy se skládají ze tří trojic bitů R, W, X (právo pro čtení, právo pro zápis a právo provykonávání) pro každého z uživatel, skupina, ostatní. Samba mapuje MS-DOS atributysouborů na UNIXová přístupová práva takto:

� read–only je uložen v bitech R a W vlastníka

� archive je uložen v bitu X vlastníka

� system je uložen v bitu X skupiny

� hidden je uložen v bitu X ostatních

Původní sémantika takto uložených atributů ovšem na UNIXových systémech nebudezachována, pouze u atributu read–only.

Protokol SMB navíc proti atributům typu MS-DOS nabízí rozšířené atributy, kterénejen pomáhají určit typ souboru, ale ještě napomáhají serveru optimalisovat přístupk souboru tím, že napovídají, jakým způsobem bude klient se souborem pracovat. Roz-šířené atributy jsou uloženy jako bitová mapa 32 bitů. Možná je jakákoliv kombinaceatributových bitů:

� ATTR READONLY

� ATTR HIDDEN

� ATTR ARCHIVE

� ATTR DIRECTORY

� ATTR SYSTEM

které mají stejný význam jako výše uvedené MS-DOS atributy, a dále:

� ATTR TEMPORARY: soubor je dočasného charakteru

� ATTR NORMAL: soubor nemá žádný speciální význam

– 56 –

� ATTR COMPRESSED: soubor je komprimován, pro adresář znamená, že nově vytvo-řené soubory jsou komprimovány.

a příznaků:

� WRITE THROUGH: všechny zápisy musí být propagovány do souboru, operační sys-tém může zápisy ukládat do cache, ale nesmí užít líné vyprazdňování cache.

� NO BUFFERING: požadavky nesmí být cacheovány, práce se souborem vyžaduje pří-stup po násobcích velikosti sektoru na svazku.

� RANDOM ACCESS: aplikace přistupuje k souboru náhodně, server by měl tuto infor-maci využít pro zoptimalisování práce s cache.

� SEQUENTIAL SCAN: soubor bude sekvenčně čten od začátku do konce, slouží k zopti-malisování práce s cache, pokud soubor nebude čten sekvenčně, sémantika operacíbude stejná, ale může dojít ke zpomalení operací.

� DELETE ON CLOSE: server soubor smaže po zavření všech file–handle, které na nějukazují.

� BACKUP SEMANTICS: soubor byl otevřen nebo vytvořen pro účely zálohování.

� POSIX SEMANTICS: k souboru se přistupuje se sémantikou POSIX, která umožňujevíce souborů se jménem lišícím se pouze ve velikosti písmen.

UNIXové souborové systémy dovolují vytvářet na soubory odkazy a symbolické od-kazy. Ve světě Windows, odkud SMB pochází, odkazy nejsou, proto je potřeba se s tímtoproblémem nějak vyrovnat. Samba server lze nakonfigurovat tak, aby odkazy následoval,tedy na Windows klientu se odkaz bude jevit stejně jako soubor. Podobně lze určit, jakse bude pracovat se soubory, jejichž jméno začíná tečkou (na UNIXu skryté soubory).

Krom běžných operací jako otevření souboru, čtení, zápis, posun na určitou poziciv souboru, zavření, vytvoření objektu, smazání, přejmenování, zkopírování, souborovýsystém SMB také obsahuje podporu dočasných souborů. Klient může zažádat o vytvořenídočasného souboru, serveru pošle cestu k adresáři, ve kterém má být dočasný souborvytvořen, server v něm vytvoří soubor s unikátním jménem, otevře ho pro čtení i zápisa vrátí klientu file–handle. Práce s dočasnými soubory je optimalisována pro krátkodobévyužití a rychlý přístup, většinu dat se server pokouší udržet v paměti a nezapisovat namédium, proto by klient měl do souboru zapisovat co nejméně.

7.3.4 Zámky

Souborové systémy MS-DOS a Windows dovolují zápis do souboru v jednom oka-mžiku pouze jednomu procesu a podporují uzamykání částí souboru určených bytovýmintervalem. Souborový systém SMB nabízí stejné služby zamykání, navíc podporuje me-chanismus tzv. oportunistických zámků, zkráceně oplocks, které jsou známy ze systémuWindows NT. Oplocks mohou být aplikovány pouze na soubory a nejedná se o zamykánív pravém slova smyslu, ale spíše o delegování operací, jak je známo z NFS4. Od klasickýchzámků se též liší v tom, že typicky jsou k dispozici pouze klientu a aplikace je explicitněpoužívat nemůže.

Oportunistické zamykání dovoluje informovat server o tom, že klient nebude provádět

– 57 –

výhradní zápis do souboru, ale pro urychlení přístupu bude změny ukládat do lokálnícache. Server, který dostane takovou informaci od klientu, označí soubor a čeká, až klientukončí práci se souborem. Jakmile klient se souborem přestane pracovat, zašle konečnézměny zpět SMB serveru pro synchronisaci. V případě, že jiný klient požádá o přístupk tomuto souboru, server zašle klientu, který drží oplock, požadavek o ukončení oplockbreak. Tím říká klientu, že má přestat ukládat změny do lokální cache a odeslal na serveraktuální data souboru, aby soubor byl k dispozici druhému klientu.

Oportunistické zámky se dělí na tři typy: exclusive, batch a level 2. Oportunistickézámky typu exclusive zaručují, že vlastník tohoto zámku je jediným klientem, který másoubor otevřený, klient může cacheovat pouze čtení a zápisy, jiné operace nemohou býtbezpečně cacheovány. Server může oplock kdykoliv vyžádat zpět, jakmile jiný klient po-žádá o otevření souboru. Zámky batch umožní klientu odložit zavření souboru v pří-padě, že soubor byl aplikací otevřen a opakovaně znovuotevřen. Sémantika je stejná jakou exclusive oplocks, navíc je zaručeno, že server vyžádá oplock zpět, jakmile se jiný kli-ent pokusí jakkoliv modifikovat soubor. Drží-li klient level 2 oplock, jiné klienty mohoumít soubor též otevřený, ale klient může bezpečně provádět cacheování čtení, žádné jinéoperace nemohou být cacheovány. Server může zámek vyžádat zpět, jakmile se jiný klientpokusí do souboru zapsat. Pokud server zruší exclusive nebo batch oportunistický zámek,čeká, až klient zapíše modifikace na server a potvrdí zrušení. V případě level 2 zámkuserver na potvrzení nečeká.

S oportunistickými zámky může nastat problém na UNIXovém Samba serveru, kterýnepodporuje v jádře oportunistické zámky. Když lokálně běžící proces přistoupí k sou-boru, který má uzamčen oportunistickým zámkem proces na vzdáleném počítači, můžesnadno dojít k poškození dat nebo přečtení neplatných dat. Podpora oportunistickýchzámků existuje v systémech SGI Irix 6.5.2f a vyšší, Linux a několika dalších. Na systé-mech nepodporujících oportunistické zámky je možno tyto v Samba serveru zakázat.

SMB nabízí několik způsobů zamčení na principu odepření přístupu jinému procesu:

� DENY NONE: nezamítne žádné další požadavky na soubor

� DENY ALL: zamítne všechny další požadavky na otevření souboru

� DENY READ: zakáže všechny další požadavky na otevření souboru pro čtení

� DENY WRITE: zakáže všechny další požadavky na otevření souboru pro zápis

� DENY DOS: pokud je soubor otevřen pro čtení, mohou ostatní soubor číst, ale nesmízapisovat, pokud je soubor otevřen pro zápis, ostatní nemohou soubor otevřít

7.3.5 Transakce

Z praktických poznatků při zkoumání práce uživatelů se souborovými systémy sezjistilo, že nejčastěji uživatelé pracují s malými soubory o velikostech v řádu desítekkilobytů. Většina síťových souborových systémů vychází z tohoto poznatku a zakládána něm mnoho optimalisací. Bez ohledu na tento fakt je ale v praxi nutné též pracovats velkými soubory velikosti řádu megabytů. Protokol SMB pro přenosy velkých objemůdat (více než 64kB) používá tzv. transakční subprotokol.

– 58 –

Komunikace probíhá následovně. Zprávy vyměňované mezi klientem a serverem nesouoznačení, že se jedná o transakce, klient nejprve vyšle serveru zprávu s prvním transakč-ním požadavkem, která mimo jiné obsahuje i celkovou velikost dat, kterou klient požadujepřenést. Pokud se všechna data vejdou do této jedné zprávy, server požadavek vykoná,vrátí klientu odpověď a tím komunikace končí. Jestliže se však všechna data do prvnízprávy nevejdou, server klientu pošle potvrzení přijetí první zprávy, které zároveň zna-mená, že klient může pokračovat ve vysílání. Klient tedy postupně odešle všechny zbylétransakční zprávy, na které již server neodpovídá potvrzením. Server transakční poža-davky postupně provede a odešle zprávy s odpověďmi na jednotlivé požadavky.

7.4 Bezpečnost

Před přístupem ke každému sdílenému prostředku se klient musí serveru autenti-zovat heslem, nebo dvojicí uživatelské jméno a heslo. Je též možné nakonfigurovat naserveru anonymní přístup, který autentizaci nevyžaduje. Výsledkem autentizace je proklient buďto odmítnutí přístupu, nebo přijetí 16 bitového identifikátoru uživatele UID,kterým klient v další komunikaci potvrzuje, že odesílané požadavky pocházejí od onohokonkrétního uživatele.

7.4.1 Autentizace uživatelů a zpráv

Během procesu autentizace mohou být hesla k serveru posílána buď v plaintextu,nebo výměna může probíhat kryptovanou formou. Starší klienty a servery vyžadují heslav plaintextu. Pokud server umožňuje kryptovanou výměnu hesel, klient by měl, pokud toje možné, kryptování hesel použít. Ověřování hesla při použití kryptované výměny heslaprobíhá způsobem challenge–response. Server pošle klientu náhodné číslo, klient s nímprovede kryptografickou operaci za použití hesla a odešle výsledek serveru. Server poténa základě znalosti hesla a odpovědi od serveru určí, zda klient použil správné heslo, nebonikoliv a podle toho uživatele přijme nebo odmítne.

Konrétně během vyjednávání verze protokolu server v odpovědi negprot reply vyšle64 bitové náhodné číslo challenge. Klient z uživatelského hesla vypočte 168 bitový sessionkey, kterým challenge pomocí algoritmu DES [52] zakryptuje, čímž vznikne 192 bitováresponse, kterou ve zprávě přihlašování sessetupX odešle (spolu s uživatelským jménema dalšími informacemi) serveru. Session key může být z uživatelského hesla převedenéhona velká písmena počítán dvěma způsoby, buďto jako tzv. LM Session Key pomocí al-goritmu DES [52] v blokovém režimu, nebo jako tzv. NT Session Key pomocí algoritmuMD4 [50]. Jak napovídají názvy, první způsob je použit v protokolu SMB, druhý v CIFS.

Komunikace mezi klientem a serverem může být od verze protokolu „NT LM 0.12ÿautentizována pomocí tzv. MAC (message authentication code), který se vypočítá zezprávy pomocí klíčované MD5 [51] s klíčem založeným na response a spočítaném sessionkey. MAC je vypočítána z obsahu zprávy i z jednoznačného identifikátoru zprávy, abynemohlo dojít k útoku opakovaným zasláním zprávy, a odeslána ve zprávě. Pokud je nazačátku komunikace dohodnuto používání MAC, zprávy začnou být autentizovány odokamžiku, kdy se provede první neanonymní zalogování uživatele, které ustaví MAC klíč.Podrobný popis kryptovacích algoritmů lze nalézt v [48] v kapitole 2.8.

– 59 –

Pokud se hesla posílají v nekryptované formě, kdokoliv může heslo odposlouchata tím získat přístup ke sdílenému prostředku. Podrobné rozebrání potenciálních útoků napoužitý algoritmus challenge–response a autentizaci zpráv a způsoby, jak se jim bránitnajdeme v [49]. Většina útoků je ekvivalentních prolomení příslušného kryptografickéhoalgoritmu. Pokud útočník podvrhne challenge serveru za svůj vhodně zvolený challengea na základě odpovědi se může pokoušet zlomit jednosměrnou funkci. Zatím však neníznám žádný způsob prolomení jednosměrné funkce DES ani s pomocí vhodně zvolenéhoplaintextu. Potenciální slabinou by tedy mohly být použité algoritmy MD4, MD5 a DES,dnes jsou již známy odolnější jednosměrné funkce jako například SHA-1 [53]. Na rozdíl odkupříkladu protokolu SRP [27] použitém v systému SFS mohou být též pro autentizačníprotokol hrozbou příliš jednoduchá uživatelská hesla. Protokol není odolný vůči odpo-slouchání přenášených dat, protože komunikace mezi klientem a serverem není šifrovaná.

Prakticky hrozící útok na klienty implementující starší verze protokolu je popsánv [54]. Útok spočívá ve využití možnosti posílání nekryptovaných hesel v protokolu. K pro-vedení útoku útočníkovi stačí získat přístup ke spojení mezi klientem a serverem. Pokudútočník během navazování komunikace mezi klientem a serverem odchytí a modifikujepacket negprot reply obsahující informaci, zda server podporuje kryptovaná hesla, tak,aby vyjadřoval, že server kryptovaná hesla nepodporuje, klient vyšle heslo v plaintextu,na což útočník čeká a heslo odchytí. Komunikace pak bude probíhat dále a uživatel nic ne-pozná. Proti tomuto útoku se lze bránit pouze zakázáním používání plaintextových hesel.Některé novější klienty v případě, že server kryptovaná hesla nepodporuje, komunikaciukončí. Bohužel existují klienty, které přejdou na plaintextová hesla.

Samotný protokol SMB není odolný proti odposlechu přenášených dat a obsahů sou-borů. Chceme-li tento druh bezpečnosti zaručit, je nutné mezi transportní vrstvu a SMBprotokol vložit další vrstvu zajišťující šifrování dat. Tento požadavek splňuje napříkladprotokol SSL [57], který se v praxi používá, ale ne každý klient je schopen s tímto protoko-lem spolupracovat. SSL podporuje například server Samba nebo klient a server WindowsNT, klienty Windows 95 a Windows 98 tento protokol nepodporují. Klienty, které nepod-porují kryptograficky zabezpečený transportní protokol, je nutné umístit na bezpečnousíť, kde nehrozí odposlech komunikace, a tuto síť oddělit od prostředí, ve kterém hrozínarušení důvěrnosti dat, pomocí SSL proxy serveru.

7.4.2 Bezpečnostní modely

SMB nabízí při přístupu ke sdíleným prostředkům čtyři modely zabezpečení: share,user, server a domain. Nejjednodušší a zároveň nejslabší model je share, který umožňujena SMB serveru každému share přidělit heslo, heslo tedy ověřuje SMB server poskytujicíslužbu. Ke share může pak přistupovat kdokoliv, kdo zná heslo, v případě prozrazeníhesla je sdílený prostředek dostupný každému. O něco silnější je model user, kde jeu každého share vyjmenován seznam uživatelů opravněných prostředek užívat a každýuživatel na serveru má přiřazeno heslo. Pro přístup k sdílenému prostředku pak je nutnéznát uživatelské jméno a odpovídající heslo. Lze tedy kontrolovat, který uživatel k sharepřistupuje, a v případě prozrazení hesla nejsou důsledky tolik fatální. V obou případechsamozřejmě lze též prostředky sdílet anonymně.

– 60 –

Nevýhoda modelu user spočívá v tom, že pokud je na síti více SMB serverů, jenutné na každém udržovat databázi uživatelů a hesel. V takovém systému se špatněprovádějí změny. Z toho důvodu je možné použít model server, který funguje stejně jakomodel user, jen s tím rozdílem, že autentizaci provádí jiný SMB server než SMB serverposkytující sdílený prostředek. Komunikace tedy probíhá následovně. Předpokládejmesituaci, kdy se uživatel U přihlašuje ke klientu K a přistupuje ke sdílenému prostředku naSMB serveru S. SMB server S ověřuje platnost hesel pomocí autentizačního serveru A.

Uživatel U zadá klientu K své jméno a heslo. K vyšle SMB serveru S žádost negprot,S kontaktuje autentizační server A zprávou negprot a v odpovědi od A získá kryptovacíklíč, který si uloží pro případné další použití. Zároveň S odešle klientu K zprávu negprot

reply obsahující kryptovací klíč. K tímto klíčem zašifruje heslo a ve zprávě sessetupX

zašifrované heslo spolu s uživatelským jménem odešle serveru S, který uživatelské jménoa zašifrované heslo předá serveru A ve zprávě sessetupX. A ověří, zda dvojice jméno–heslo je platná, a tuto informaci odešle S. S zruší relaci s A a propaguje odpověď směremke klientu K. Tento princip se nazývá Pass–Through autentizace [41].

Ve všech třech případech je výsledkem autentizace pouze jednobitová informace, zdaje uživatelské jméno a heslo platné. V některých případech je potřeba během autentizacezískat i další údaje jako celé jméno, popis uživatele, profil a další. Tyto údaje lze získatpoužitím bezpečnostního modelu domain.

Protokol logování domain [41] je použit v doménách Windows NT [35]. Windowsdoména je skupina počítačů (CIFS serverů a uživatelských stanic), která obsahuje serverřadič domény (DC — Domain Controller). Řadič domény koordinuje práci serverů a držídatabázi uživatelských účtů SAM (Security Account Manager) a zajišťuje autentizaciuživatelů do celé domény, jeho funkce je podobná serveru NIS v sítích UNIX. Řadičůmůže být v doméně víc, hlavní z nich se označuje jako PDC.

Každý CIFS server v doméně se po svém startu přihlásí k PDC, který ho mechanis-mem challenge–response vyžádá k autentizaci, po jejím úspěšném absolvování komunikaceprobíhá bezpečným kanálem. Klient, který chce přistupovat ke sdílenému prostředku, sespojí se serverem a autentizuje se stejným způsobem jako v bezpečnostním modelu user:klient kontaktuje CIFS server, ten odešle klientu challenge, klient zašifrováním challengepomocí uživatelova hesla vytvoří response a tu spolu s uživatelským jménem vrátí CIFSserveru. CIFS server ovšem nezná uživatelovo heslo, neboť to je uloženo v SAM databázina PDC, a tedy nemůže ověřit, zda response od klientu je správná. Proto po bezpeč-ném kanále odešle klientovu response PDC, který uživatele autentizuje, Tento způsobautentizace se nazývá NetLogon [58].

Firma Microsoft oznámila, dle [35], že v protolu CIFS v systému Microsoft Windows2000, se stane standardním autentizačním mechanismem a bezpečnostním protokolemsystém Kerberos 5.0 [21]. Open–source SMB implementace Samba podporuje systémyKerberos 4.0 i Kerberos 5.0. Dokumentace k této verzi CIFS protokolu však není volnědostupná, proto bohužel nebylo možno tento aspekt blíže zkoumat.

– 61 –

8. Andrew File System


AFS je robustní distribuovaný souborový systém, který umožňuje efektivně sdíletdata po lokální i vzdálené síti. Autorem AFS je firma Transarc Corporation, která tentosouborový systém komerčně prodává. AFS je založeno na distribuovaném souborovémsystému Andrew File System původně vyvinutém v Centru Informačních Technologií naCarnegie–Mellon University.

Návrhu AFS předcházel distribuovaný souborový systém DFS, který počátkem osm-desátých let minulého století, kdy s nástupem stolních počítačů výpočetní model přešelz velkých sálových počítačů na prostředí pracovních stanic, vyvinula též firma Transarc.DFS bylo součástí systému distribuovaného výpočetního prostředí DCE. Základní myš-lenka DFS spočívala v poskytnutí přístupu k souborům bez ohledu na jejich fyzickéumístění, neboť v době zrození DFS vznikl problém s rozmístěním souborů na mnohapočítačích a nejednotným přístupem k souborům, a nabídnutí jednotné množiny operací,pomocí nichž se k souborům přistupuje.

DFS ale bylo navrženo pro lokální sítě a s nástupem rychlých linek spojujících lokálnísítě přišla potřeba DFS rozšířit i na rozlehlé sítě WAN a tak vytvořit tzv. WADFS(Wide Area Distributed File System). AFS se stalo prvním komerčním WADFS. PůvodníAndrew File System byl navržen k poskytování distribuovaného souborového systému proCarnegie–Mellon University — pro přibližně 10 000 uživatelů, jejichž pracovní stanicebyly umístěné v clusterech. Po uvedení do provozu a otestování se zjistilo, že by AFSmohlo být rozšířeno, aby spojovalo jednotlivé oblasti dosud v AFS autonomní. Proto bylyspodní komunikační vrstvy AFS upraveny, aby se lépe přizpůsobily rozličným přenosovýmcharakteristikám sítě, zejména rozdílům v rychlosti mezi lokální sítí a vnější sítí.

Firmu Transarc později koupilo IBM, které uvolnilo zdrojové kódy AFS veřejnosti.Tak vznikl projekt OpenAFS otevřené implementace AFS.

Na Královské technické universitě ve Stockholmu ve Švédsku vznikla roku 1993 volnáimplementace AFS jménem ARLA. Cílem tohoto projektu bylo napsat volnou alter-nativu AFS, jež bude obsahovat funkce a podporovat platformy, které AFS od firmyTransarc dosud nepodporuje. Mezi podporované platformy patří BSD, Linux, Solarisa Darwin/MacOS X. Částečně je též podporován SunOS, AIX, IRIX, Digital UNIXa HPUX. Projekt je dosud ve vývoji, některé části dosud nejsou plně implementoványnebo nefungují vůbec. Práce byla zejména věnována klientským součástem AFS.

8.1.1 Cíle AFS

Cílem AFS se stalo rozšířit služby UNIXového souborového systému do prostředísítí WAN. Architektura AFS je klient–server, data jsou centrálně skladována na serve-rech, které je umožňují číst klientům. AFS bylo navrhováno jako robustní komplexnísystém, který umožní poměr klientů k jednomu serveru v řádu 200 : 1, pokrytí organisacís desítkami tisíc uživatelů a umožnění spojení tisíců nezávislých autonomních organisacív jednom sdíleném jmenném prostoru bez vnějšího koordinátora.

– 62 –

Systém AFS nabízí při práci se soubory přístupovou a lokační transparenci. Přístu-pová transparence je definována jako jednotný mechanismus pro práci se soubory bezohledu, zda jsou lokální, nebo umístěné na vzdáleném stroji. Lokační transparence zne-možňuje uživateli určit, kde v systému je soubor uložen, čehož důsledkem je možnosttransparentní migrace nebo replikace souborů mezi servery.

Objekty souborového systému AFS jsou uloženy na serverech, které přijímají poža-davky od klientů, a pokud je klient autorizován operaci provést, server ji vykoná. Serverykrom souborových operací vykonávají též funkce autentizace, mapování mezi jmennýmia číselnými identifikátory uživatelů, časové služby a administrativní operace jako rekon-figurace systému, záloha nebo disk management.

8.2 Architektura

Klient i server AFS jsou postaveny nad komunikačním jádrem Rx [60]. Toto jádrointegruje vzdálené volání RPC s bezpečným přenosem a autentizací komunikujících stran.RPC použité v AFS se liší od RPC firmy Sun Microsystems [5][6][7], je popsáno v [60].Hlavním aspektem návrhu vrstvy je jednoduchost a oddělitelnost. Tato vrstva není závislána AFS a lze ji použít samostatně při psaní jiných distribuovaných aplikací.

Komunikace vrsty Rx využívá transportního protokolu UDP, služby Rx jsou spe-cifikované trojicí (IP adresa, UDP port, serviceID). Jelikož síťový přenos probíhá nadprotokolem UDP, který nezaručuje pořadí ani spolehlivost doručení, Rx implementujevlastní mechanismus identifikace komunikujících stran, doručování síťových zpráv, potvr-zování, multicastu a dalších. Rx si takto vlastní cestou vytváří spojení — autentizovanýkomunikační kanál umožňující přenášet sekvenci několika asynchronních volání současně.Spojení jsou identifikována číslem ID. V případě pádu klientu a následném restartu můžedojít k znovupoužití spojení se stejným číslem, což by mohlo vést k nekonsistenci. Z tohodůvodu každé spojení krom identifikačního čísla nese číslo epoch označující čas navázáníspojení klientem. Klient v případě restartu vygeneruje nové číslo epoch.

Autentizační mechanismus obsahuje dvě vestavěná autentizační schemata null a rx-kad, první neprovádí žádnou autentizaci, druhé označuje autentizaci protokolem Kerberos[13]. Krom těchto dvou schemat lze Rx rozšířit o libovolné další autentizační schema.

Součástí specifikace Rx jádra je též balík LWP zajišťující plánování vláken v uživa-telském módu. LWP dovoluje asynchronně a konkurentně vykonávat procedury napsanév jazyce C. Plánovač je založen na prioritách, plánuje preemptivní i kooperativní, přikooperativním plánování procedury přepínají buď explicitně zavoláním přeplánovávacífunkce, nebo implicitně v některých volaných funkcích. Krom plánování LWP přináší téždalší programátorskou podporu jako zamykání, čekání na události, časování a další.

8.2.1 Volume

Servery nevyužívají žádného hostitelského souborového systému, ale používají vlastníformát pro ukládání dat na disku, při instalaci serveru je nutné vyhradit zvláštní diskovýoddíl. Adresáře v diskovém oddílu nejsou uloženy přímo, ale ve strukturách nazvanýchvolume. Velikost volume se dynamicky mění, jak jsou soubory přidávány a mazány. S kaž-dým volume je asociována quota určující horní limit sumy velikostí souborů uložených ve

– 63 –

volume. Volume jsou identifikována 32 bitovým číslem volumeID nebo řetězcovým identi-fikačním jménem volume name. Vnitřně je struktura volume organisována jako pole pro-měnlivých objektů representující jednotlivé soubory a adresáře. Každému objektu v tomtopoli jsou přiřazeny dva identifikátory uniquifier a data version number.

Objekty souborového systému AFS jsou vnitřně identifikovány pomocí FID. FIDje definováno jako uspořádaná trojice (volumeID, index, uniquifier), kde volumeID jeidentifikátor volume, na kterém je objekt uložen, index označuje pozici v poli ve volumea uniquifier je číslo uniquifier přiřazené k danému objektu souborového systému. Tatotrojice zhruba odpovídá na UNIXovém souborovém systému trojici (fsid, inode, gene-ration number). Číslo uniquifier se po každém znovupoužití indexu v poli zvýší o 1 a dataversion number určující verzi dat souboru, kde vyšší číslo znamená novější verzi, se zvýšío 1 při každé změně objektu souborového systému.

Pro příklad [59] předpokládejme soubor example.txt, který se nachází na volume Va indexu I a jehož uniquifier je 1 a data version number 0, tento soubor je identifikovántrojicí FID=(V, I, 1). Když klient přepíše data souboru, data version number se zvednena 1, ale soubor bude určen stále stejným FID. Pokud klient soubor smaže a vytvořínový soubor například a.out, index I ve volume V může být znovu užit. V tom případěsouboru a.out bude odpovídat FID=(V, I, 2) a data version number opět klesne na 0.

Systém AFS umožňuje pomocí volume provádět replikaci, relokaci a zálohování sou-borů. Replikace a relokace volume najde uplatnění zejména k rozložení nebo balancovánízátěže disků nebo serverů. Z každého volume může administrátor pořídit read–only ob-raz, takovýto klon může být umístěn až na osm diskových oddílů na stejném stroji nebona jiných serverech. VolumeID všech klonů jsou identická, ale různá od originálu, protov jednom diskovém oddílu může být maximálně jeden klon originálu. Reference na ob-jekty v read–only klonech daného volume jsou obsluhovány kterýmkoliv serverem, kterýdrží kopii. Read–only klony mohou pomoci v některých případech k zamaskování páduserveru, zejména jde-li o nepříliš často se měnící data. Například havaruje-li server po-skytující souborový systém s aplikačními programy, lze použít read–only kopii na jinémdostupném serveru.

Volume mohou být transparentně přesouvána mezi diskovými oddíly na daném ser-veru nebo mezi jednotlivými servery. Relokace může být prováděna transparentně z tohodůvodu, že ani názvy souborů, ani FID popisující objekty souborového systému neobsa-hují informaci o umístění objektu. Přerušení služeb souborového systému pro dané volumeběhem přemisťování je v řádu sekund bez ohledu na velikost dat v relokovaném volume.Algoritmus stěhování sestává ze čtyř fází. V první fázi je pořízen obraz obsahu volumea tento obraz je umístěn na nový server. Druhá fáze zahrnuje zamčení obsahu volumea zachycení změn oproti stavu z první fáze. Ve třetí fázi jsou změny aplikovány na novýserver a čtvrtá fáze původní volume smaže. Od tohoto okamžiku budou veškeré referencena dané volume vyřizovány novým serverem.

Pomocí volume lze též provádět zálohu za běhu systému a obnovu dat. Podrobný po-pis lze nalézt v [72]. Zálohování probíhá v několika krocích, nejprve se vytvoří z každéhovolume, které má být archivováno, zálohové backup volume. Zálohové volume je organiso-

– 64 –

váno jako copy–on–write shadow obraz zachycující stav originálního volume v okamžikuuskutečnění zálohy. Zálohové volume se skládá z množiny odkazů do původního volume.V případě provedení jakékoliv změny původního volume se odkaz na příslušný objektv zálohovém volume nejprve zruší, z původního volume se objekt zkopíruje do záloho-vého volume a teprve pak se zapíše změna objektu do originálního volume.

Tento mechanismus nese několik výhod. Záloha může být vytvořena bez přerušeníběhu systému a zálohované volume nemusí být odstaveno na dlouhou dobu — odkazylze vyrobit ve velice krátkém čase. Typicky zálohové volume zabírá velice málo místa,neboť se do něj kopírují pouze objekty, které byly po záloze modifikovány. Kopírovánízálohovaných dat na zálohovací médium (např. pásku) může být provedeno kdykoliv poprovedení zálohy.

8.2.2 Buňky

Systém AFS nabízí jednotnou adresaci a přístup k souborům na všech strojích pocelém světě. Síť je rozdělena na tzv. buňky, což jsou skupiny klientů a serverů, kteréadministrativně tvoří jednotný celek. Každý klient nebo server v AFS náleží právě dojedné buňky. Myšlenka AFS je taková, že buňka odpovídá počítačům nějaké organisace[66][67], typicky buňka odpovídá počítačům v jedné internetové doméně (například buňkams.mff.cuni.cz) a také je většinou pojmenována podle doménového jména.

Koncept rozdělení administrativní organisace prostoru AFS na buňky umožňuje indi-viduální autonomní správu jednotlivých oblastí a současně vytvoření jednotného globál-ního jmenného prostoru jako sjednocení jmenných prostorů členských buněk. Za kořenjmenného prostoru AFS se pro každou buňku bere jedno volume, obvykle pojmenovanéroot.afs. Každný klient v buňce připojí toto kořenové volume do adresáře /afs pomocíUNIXové operace mount, čímž v /afs zpřístupní celý jmenný prostor AFS. Adresářovéstromy jednotlivých buněk lze nalézt v adresáři /afs/<jméno buňky>, tedy napříkladbuňce ms.mff.cuni.cz odpovídá adresář /afs/ms.mff.cuni.cz.

8.2.3 Server

Serverová část AFS buňky se skládá z několika důležitých komponent, které mohoufyzicky běžet buďto na jednom počítači jako jednotlivé procesy, nebo každá komponentana jiném počítači. Těmito komponentami jsou následující procesy běžící v uživatelskémmódu operačního systému serverového stroje:

� File Server[64]: Samotná data souborového systému jsou ukládána na souboro-vých serverech, těch může být v buňce několik, data mezi nimi mohou být pře-misťována nebo kopírována. Granularita dat v rámci file serverů je omezena najednotlivá volume.

� Volume Location Server[61]: Tento proces má za úkol udržovat a exportovatdatabázi umístění jednotlivých volume VLDB (Volume Location Database), kteráobsahuje server nebo množinu serverů, na kterých je konkrétní instance volumeumístěna. Tato služba podporuje operace jako zjištění umístění volume, zjištěnístavových informací o volume, management volumeID, vytváření, mazání a modi-fikace položek VLDB databáze.

– 65 –

VLDB může též být z důvodu vyvážení zátěže nebo zvýšení propustnosti repliko-vána na více fyzických serverů. Proces Volume Location Server běží na každémpočítači, který drží kopii VLDB, a spravuje tuto kopii databáze.

� Volume Server[61]: Umožňuje provádět administrativní úkony na množině AFSvolume sídlících na počítači, na kterém běží. Mezi tyto operace patří vytvářenínových volume, mazání, přejmenovávání volume, zálohování a obnovování volume,změna seznamu replikačních míst, vytváření read–only obrazů volume, získáváníinformací o stavu volume a další.

� Authentication Server[63]: Tento proces udržuje a exportuje autentizační da-tabázi ADB (Authentication Database), která schraňuje zakryptovaná hesla všechuživatelů v buňce. Authentication Server nabízí rozhraní pro administraci data-báze ADB, implementuje vzájemný autentizační protokol Kerberos a vydáváníidentifikačních ticketů úspěšně přihlášeným uživatelům.

Autentizační databáze může být ze stejných důvodů jako VLDB databáze repli-kována na více strojů, Authentication Server pak běží na každém počítači držícímdatabázi ADB a obhospodařuje tuto kopii. Implementační specifikaci lze naléztv [63].

� Protection Server: Udržuje databázi PDB (Protection Database) mapovánímezi jmennými identifikátory uživatelů a skupin a jejich číselnými representacemiv AFS. Protection Server též umožňuje obecnou manipulaci se záznamy o uživa-telích a skupinách v AFS.

Databáze PDB opět může být replikována na více strojích, Protection Server pakběží na každém z nich.

� BOS Server[62]: Tento proces běží na každém souborovém serveru v buňce a nesezodpovědnost za monitorování stavu souborového serveru, za správné spuštění pro-cesů po startu počítače, automatické restartování procesů v případě pádu a sbíráníinformací o stavu jednotlivých procesů serveru. Slouží též jako administrativní ná-stroj pro instalaci binárních programů serveru a pro management.

Komunikace BOS serveru s ostatními procesy probíhá jednostranně, iniciována jevždy BOS serverem. Komunikace probíhá formou UNIXových signálů.

� Update Server/Client: Tato dvojice programů slouží k distribuci systémovýchsouborů a binárních kódů serveru.

Uvedené systémové databáze VLDB, ADB a PDB jsou implementovány pomocí dis-tribuované databáze ubik [69]. Přístup do distribuované databáze je zprostředkován pro-cesy běžícími na jednotlivých serverech. Distribuovaná databáze se skládá z množinysouborů replikovaných na množinu serverů. Je navržena tak, že jeden ze serverů je zvolenjako synchronisační centrum. Synchronisační centrum jako jediné přijímá požadavky nazápis do databáze, ostatní servery umožňují pouze čtení databáze. Operace s databází seprovádí v rámci transakcí, pokud všechny operace v transakci proběhnou úspěšně, trans-akce je potvrzena a změny trvale uloženy do databáze. V opačném případě je transakcezrušena a změny nejsou provedeny. Jakmile synchronisační server přijme a vykoná poža-

– 66 –

davek na změnu databáze, distribuuje aktualisovanou verzi ostatním serverům. Dojde-lik pádu synchronisačního centra nebo k výpadku sítě, zbylé servery automaticky zvolínové synchronisační centrum, pokud vytvoří většinu [70].

Podobně jako komunikační část AFS Rx, i databáze ubik je navržena jako samostatnýcelek nezávislý na AFS. Lze ji tedy použít i v rámci jiných distribuovaných aplikací.

8.2.4 Jmenný prostor

Adresářové stromy obsažené na jednotlivých volume daného serveru jsou spojenyv jednotnou adresářovou strukturu tvořící jeden UNIXový adresářový strom. Místo, kamje umístěn adresářový strom konkrétního volume, se nazývá mount–point. Mount pointje persistentní objekt souborového systému implementovaný jako symbolický odkaz jehožobsah se podrobuje konkrétnímu formátu, viz [64] 6.4.2 a 6.4.4.4. AFS mount–point seliší od UNIXových mount–pointů, jak jsou známy například z NFS. V NFS uživateldynamicky připojuje vzdálený adresář do libovolného místa svého lokálního adresářovéhostromu. Toto připojení vydrží pouze do restartu klientu a nezajistí jednotný jmennýprostor mezi různými servery.

Při překladu adresářové cesty AFS klient kontaktuje příslušný Volume Location Ser-ver, jehož adresu má uloženu v konfiguračním souboru, aby zjistil, na kterém File Serverunebo množině File Serverů sídlí volume připojené v daném mount–pointu. Získanou in-formaci uloží v cache pro další překlady. Postupně kontaktuje File Servery, dokud jedenneodpoví obsahem kořenového adresáře volume. Jakmile klient získá kořenový adresář,pokračuje s překladem běžným způsobem a komunikuje pouze s příslušným File Serverem.

8.3 Bezpečnost

8.3.1 Bezpečnostní model

Z bezpečnostního hlediska jsou servery v jedné administrativní doméně považoványza bezpečné a AFS předpokládá, že jsou „umístěny za zamčenými dveřmiÿ a že s nimimanipulují pouze spolehliví administrátoři. Servery v jedné administrativní doméně ne-smí svojí (ne)bezpečností (například laxním přístupem tamního administrátora) ohrozitbezpečnost serverů jiné administrativní domény. O klientských stanicích se předpokládá,že jsou plně v rukou uživatelů a tedy nedůvěryhodné. Klienty v bezpečnostním modeluAFS mohou být modifikovány ať už zasahy do hardware, firmware, operačního systémunebo aplikačního software.

8.3.2 Autentizace

AFS používá k autentizaci uživatelů bezpečnostní systém Kerberos [13][21][14]. Ker-beros poskytuje vzájemnou autentizaci, nejen zaručuje serveru, že k němu přistupujeuvedený uživatel, ale také zajišťuje klientům, že pracují opravdu s daným serverem a nes útočníkovým podvrženým strojem. Bezpečnost je zajišťována systémem tzv. ticketů.Uživatel si při vytváření účtu v systému u autentizačního serveru registruje heslo, kte-rým se při práci se systémem autentizačnímu serveru bude prokazovat. Chce-li uživatelvstoupit do systému, kontaktuje autentizační server a prokáže se heslem. Je-li heslo platné,autentizační server vrátí klientu autentizační ticket, který se uloží v části AFS klientu

– 67 –

běžící v operačním systému. Ticket obsahuje zakryptované uživatelovo jméno, klíč, ča-sovou značku vydání a časovou značku doby expirace. Z těchto bezpečnostních důvodůje nutné v prostředí AFS zajistit mezi klienty a servery časovou synchronisaci, v praxik tomuto účelu slouží protokol NTP (Network Time Protocol) [73]. Chce-li klient přistu-povat k souborovému serveru, musí se mu uživatelem získaným ticketem autentizovat.Pokud je souborový server schopen ticket dešifrovat, znamená to, že ticket byl vytvořenautentizačním serverem a žadatel o přístup k serveru je osoba identifikovaná ticketem,přístup k serveru tedy může být povolen.

Při vzniku AFS byl k dispozici pouze Kerberos verze 4 [13], v dnešní době se po-užívá Kerberos 5 [21], který je v AFS již také implementován. Podrobnější informaceo systémech Kerberos lze nalézt v uvedené literatuře.

8.3.3 Autorizace

Standardní UNIXová přístupová práva representovaná bitovou maskou asociovanous každým objektem souborového systému, jež byla aplikována na základě numerickéhoidentifikátoru uživatele a uživatelova členství v rozličných skupinách, se jevila jako nedo-statečná, proto AFS přišlo s vlastním modelem přístupu k objektům.

Krom standardní UNIXové přístupové bitové masky AFS pro detailní specifikaci pří-stupu a povolených operací ke každému adresáři přiřazuje seznam ACL. AFS UNIXovápráva nepoužívá, namísto nich pracuje s ACL, z bitové masky UNIXových práv respektujepouze příznak „xÿ pro označení spustitelného souboru. V ACL může figurovat uživatelnebo skupina, práva mohou být libovolnou kombinací následujících:

� Read (r): principal může číst obsahy souborů v adresáři.

� Lookup (l): v adresáři lze vyhledávat jména objektů.

� Write (w): právo vytvářet nové objekty a přepisovat obsahy existujících objektův adresáři.

� Insert (i): možnost vkládat nové objekty do adresáře, ale ne přepisovat existujícíobjekty.

� Delete (d): právo mazat objekty v adresáři.

� Lock (k): povolení získat a uvolnit doporučené zámky na daný adresář.

� Administer (a): možnost měnit ACL adresáře.

Granularita ACL omezující se na celý adresář nese nevýhodu, že UNIXové hard linkylze vytvářet pouze v rámci jednoho adresáře. Symbolické linky mohou být použity stan-dardně a bez omezení.

Krom uživateli vytvořených skupin systém AFS nabízí tři speciální vestavěné sku-piny:

1) system:anyuser: Členem této skupiny se stává každý uživatel, který přistupujek souborovému systému AFS, bez ohledu na to, zda drží autentizační tiket nebonikoliv. Tato skupina je zajímavá tím, že nemá pevně vyjmenované členy, skupinaautomaticky roste a zmenšuje se podle toho, jak uživatelé přistupují k souboro-vému systému.

– 68 –

Využití skupiny system:anyuser se typicky uplatní na ACL seznamech adresářů,do kterých má být povolen plně veřejný přístup zahrnující všechny uživatele při-stupující z kteréhokoliv AFS systému.

2) system:authuser: Do této skupiny patří všichni uživatelé, kteří jsou oprávně-nými držiteli Kerberos ticketu získaného u autentizačního serveru dané buňky.Podobně jako skupina system:anyuser i tato skupina nemá pevně vyjmenovanéčleny. Jakmile uživatel obdrží ticket od autentizačního serveru, automaticky sestává členem této skupiny, až platnost ticketu vyprší, uživatel ze skupiny automa-ticky odchází.

Skupina system:authuser se většinou používá pro adresáře se speciálním význa-mem pro intranet, pro organisaci provozující AFS.

3) system:administrators: Tato vestavěná skupina zahrnuje uživatele oprávněnéprovádět důležité administrativní operace uvnitř buňky. Členové skupiny sys-

tem:administrators mají explicitně nastavené právo „aÿ v ACL každého adre-sáře v AFS buňce. Na rozdíl od předchozích dvou skupin musí být uživatelé doskupiny přidáváni a ze skupiny ubíráni explicitně.

Tato skupina se typicky používá v ACL adresářů, které obsahují citlivé informaceo systému, se kterými mohou manipulovat pouze administrátoři. Všichni členovéskupiny mají implicitní právo měnit ACL kteréhokoliv AFS adresáře v buňce,proto nemusí být explicitně uvedeni v ACL adresáři, aby byli schopni s ACL ma-nipulovat. Jedině členstvím v této skupině lze vykonávat administrativní příkazyna souborových serverech v buňce.

8.4 Klient, datová cache

Klientská část AFS nazývaná Cache Manager běží v jádře operačního systému klient-ského počítače a jejím úkolem je representovat uživatele v komunikaci a interakci s FileServery. Jak napovídá název, primární úkol Cache Manageru tkví v komunikaci se sou-borovými servery a ukládání vzdálených AFS souborů v cache na lokálním disku klientua tak vytvářet ilusi, že vzdálené soubory sídlí na lokálním disku. Veškeré operace se sou-bory jsou přes rozhraní VFS [71] směrovány Cache Manageru, který operace provádí nakopii souboru v lokální cache. Cache Manager je též odpovědný za zpracování UNIXo-vých souborových cest a mapování každé komponenty cesty na přístlušný File Servernebo skupinu File Serverů, které poskytují volume s daným souborem.

Cache Manager je připojen do operačního systému klientu přes rozhraní VFS, coždovoluje snadný přenos AFS na jiné operační systémy.

Krom těchto funkcí Cache Manager též zajišťuje synchronisaci času se spolehlivýmzdrojem času, udržování bezpečnostních ticketů a jejich používání při komunikaci se sou-borovými servery, získávání a udržování informací o umístění jednotlivých volume zjiště-ných dotazy do VLDB.

Soubory v cache na disku nejsou ukládány vcelku jako u jiných síťových souborovýchsystémů, ale po blocích, což umožňuje cacheovat libovolně velké soubory bez ohledu navelikost klientské cache. Granularitu bloků ukládaných souborů lze individuálně nastavit

– 69 –

na každém klientu, výchozí hodnota je 64 kilobytů, což zajišťuje, že většina souborů,se kterými klient pracuje, půjde umístit do jediného bloku. Výhoda ukládání na diskuspočívá v tom, že data zůstanou v cache i po případném rebootu klientu.

8.4.1 Callback

Konsistence klientské souborové cache je zajišťována mechanismem callbacků. Jakmileserver dodá klientu jeden nebo více cacheových bloků souboru, callbackem zaručuje, žesoubor nebude modifikován. To klientu umožňuje pracovat se souborem bez další interakcese serverem. Pokud jiný klient soubor modifikuje a uloží změny na server, server callbackzruší, čímž klientu oznámí změnu. Není-li soubor delší dobu modifikován, callback můžečasem vypršet.

Následující příklad ilustruje princip callbacku. Klient A otevře soubor S a začne z nějčíst. Mezitím klient B soubor S také otevře, zapíše do něj a zavolá close() nebo fsync(),čímž se změny dostanou na server. Nežli server změny akceptuje a zapíše je na disk, rozešlevšem klientům, kteří obdrželi kopii souboru S, požadavek na zrušení callbacku, mezi nimii klientu A, který callback zruší. Ovšem aplikace běžící na A a pracující se souboremS nezjistí, že došlo ke zrušení callbacku, a požádá-li o další čtená data, získá nová datazapsaná klientem B.

AFS rozlišuje tři typy callbacků [64]. První typ EXCLUSIVE zaručuje Cache Manageru,kterému byl callback vydán, výhradní držení souboru, ale dosud není implementován.Callback SHARED se používá v případě sdílení souborů jedním nebo více Cache Managerya zaručuje aktuálnost dat vzhledem ke stavu na serveru. Tento typ odpovídá výše uvede-nému popisu. Třetí typ DROPPED označuje stav, kdy server přestal ručit aktuálností data Cache Manager při přístupu k datům nemůže použít data v lokální cache, ale musípožádat server o zaslání aktuální verze dat.

Mechanismus callbacků se nevztahuje na read–only volume, přesto je potřeba read–only volume synchronisovat se serverem, aby nedošlo k použití zastaralých dat klientem.Klony volume určené pouze pro čtení jsou synchronisovány jako celek. Každá odpověďna RPC volání z klientu na server používané pro práci s read–only volume obsahuječasovou informaci o datu vytvoření tohoto volume. Cache Manager při získání odpovědina RPC volání vždy kontroluje, zda čas vytvoření klonu uvedený v odpovědi souhlasís časem cacheovaného bloku, s kterým se pracuje, v kladném případě použije data uloženáv cache, v případě nesouhlasu označí všechny cacheované bloky uložené na tomto volumeza podezřelé a při příštím přístupu na některý z těchto bloků kontaktuje nejprve příslušnýFile Server, aby dodal novější verzi dat.

8.4.2 Odlišnosti v sémantice

Díky uvedenému návrhu cache se sémantika souborového systému AFS liší od sé-mantiky lokálního UNIXového souborového systému [15] v promítání změn do souborupři zavolání systémového volání write(). Na rozdíl od UNIXového lokálního souboro-vého systému, kde se po zavolání write() změny promítnou okamžitě na disk, zpožděnépouze vyrovnávací pamětí pro zápis na disk, v AFS se změny po zavolání write() pro-mítnou okamžitě pouze do lokální cache klientu. Na server jsou změny zapisovány až po

– 70 –

zavření souboru nebo explicitním vyprázdněním vyrovnávacích pamětí voláním fsync().Přestože [68] uvádí, že v praxi uvedené odlišnosti v sémantice AFS nejsou na závadu,s touto pozměněnou sémantikou musí být počítáno při konkuretním zápisu do souboruvíce procesů běžících na různých strojích.

Kernelová část AFS rozšiřuje systémové volání ioctl() o možnost provádění AFSoperací, konkrétně o dvě nová volání VIOCLOSEWAIT a VIOIGETCELL. Volání VIOCLOSEWAITkteré zajistí, že všechny budoucí souborové operace close() zablokují volající proces,dokud nedojde k zapsání modifikovaných dat na příslušný File Server. VIOIGETCELL vrátíjméno buňky, ve kterém objekt popsaný zadaným FID sídlí.

Dále zavádí nové systémové volání pioctl(), jehož sémantika je velice podobnásémantice volání ioctl(), liší se pouze tím, že nepracuje s objektem popsaným file–handle, ale s objektem popsaným adresářovou cestou. Systémová volání pioctl() sou-hrnně umožňují manipulaci s ACL, zjišťování informací o volume a souborových serverech,práci s autentizačními informacemi a tokeny, manipulaci s cache, zjišťování FID objektů,práci s AFS mount–pointy a další. Podrobnější informace o jednotlivých voláních uvádí[64] v kapitole 6.4.

Zamykání souborů na AFS neodpovídá způsobu zamykání podle normy POSIX. Lišív tom, že na AFS lze zamykat pouze celé soubory, zamykání bytových intervalů v souborunení podporováno, přestože systémová volání fcntl() a lockf() při pokusu o zamknutíčásti souboru neskončí s chybou, AFS pouze vygeneruje varovnou hlášku. Synchroniso-vat přístup do souboru pomocí souborových zámků mohou procesy jen na stejném AFSklientu, pokus o zamknutí souboru procesem z jiného klientu skončí návratovým kódemEWOULDBLOCK.

AFS nepodporuje bloková a znaková speciální zařízení, FIFO, ani pojmenované roury.UNIXové hard–linky smí být užity z důvodů aplikace ACL kontroly přístupu pouze vestejném adresáři. Překročil-li by rozsah hard–linku hranici adresáře, mohlo by dojít k po-rušení přístupových práv ACL, proto AFS toto nedovoluje.

– 71 –

9. Novell


Souborový systém Novell je součástí síťového operačního systému NetWare určenéhopro realizaci sítí klient–server. Tento operační systém běží na serveru, který nabízí svésouborové a další služby klientům rozličných architektur.

Jak uvádí [74], historie NetWare sahá až do roku 1983, kdy byla vydána prvníverze 1.0, která nabízela jednoduchý přístup k souborům, víceúlohovost, zabezpečenípřístupu k síti a podporu pracovních stanic DOS. V roce 1986 vyšla verze 2.0, která při-nesla zvýšení odolnosti a možnost propojení více sítí v jeden celek, tato verze přinesla téžpodporu klientů Macintosh a OS/2. S nástupem 32 bitové architektury počítačů PC roku1989 Novell přišel s třetí generací svého operačního systému NetWare 3.0, která krom zvý-šení výkonu, flexibility a bezpečnosti přinesla i podporu zaveditelných modulů, TCP/IPa výkonnější souborový systém. K podporovaným klientům přibyl i systém Windows.

Čtvrtá generace roku 1993 přinesla zásadní rozdíly oproti předchozím verzím, zejménapřechod od systémové databáze Bindery ke službám NDS a rozsáhlou podporu grafickéhouživatelského rozhraní, podporu vícejazyčného prostředí. K vlastnostem souborového sys-tému přibyla možnost pakování souborů, dělení bloků a odsouvání dat. Ve verzi 4.11 přišlapodpora SMP a rozšíření služeb TCP/IP. V roce 1998 nastoupil NetWare 5, který již plněintegroval TCP/IP a aplikace napsané v jazyce Java. Roku 2001 byl vydán NetWare 6,který přinesl další zdokonalení.

Ve světě UNIXu existují pouze dvě implementace souborového systému Novell. Kon-krétně se jedná o komerční klient a server Unixware a NCP klient v Linuxu. Poslednízmiňovaný je dostupný zdarma ve formě zdrojových textů a nabízí základní funkčnostk propojení Linuxu s Novell serverem. Další klienty najdeme na operačních systémechDOS, OS/2 a Windows.

Celý systém je proprietární a uzavřený, proto není dostupná dokumentace k protokoluani k souborovému systému serveru. V dnešní době se již nejedná o rozvíjející se platformu,nicméně tento systém je stále v mnoha institucích používán.

9.2 Architektura

Server Novell nabízí současně služby souborového systému, pracuje jako autentizačníserver, obsahuje databázi uživatelů a nabízí další služby systému (například tisk). Celýběh serveru je závislý na jediném počítači. Od verze 4 Novell umožňuje vytvořit více ser-verů, které se v případě výpadku navzájem zastupují [74]. Ve verzi 6 Novell byl tento mo-del zdokonalen o možnost vytvoření clusteru serverů, které navenek vystupují jako jedenserver a sdílí externí diskové pole. Model však neumožňuje rozdělování zátěže a replikacinebo migraci dat mezi servery [74].

V prostředí sítě může být několik souborových serverů. Do verze 3 se uživatelé kekaždému serveru autentizovali samostatně a každý server držel vlastní databázi uživatelů,což bylo nepohodlné z hlediska správy. S příchodem verze 4 a databáze NDS [75] seuživatelé přihlašují k systému jako k celku.

– 72 –

Komunikace probíhá na protokolu IPX/SPX, od verze 5 též na protokolech TCP/IP.Linuxový klient podporuje komunikaci pomocí IPX i pomocí UDP.

9.3 Souborový systém

Server organisuje data na disku ve vlastním souborovém systému. Jelikož se jednáo proprietární řešení, o vnitřní struktuře diskového souborového systému nebylo možnomnoho zjistit. Disk je rozdělen na logické oddíly volume, ve kterých jsou uloženy sou-bory a adresáře. Souborový systém se vyznačuje velice silným cacheováním v paměti,do verze 3 server prakticky všechna metadata ukládal pouze do paměti, čímž dosahovalvelmi vysokého výkonu. V případě havárie je však tato politika nevyhovující, neboť dojdeke ztrátě dat, proto v pozdějších verzích server více využívá disku.

Objekty jsou identifikovány pomocí 32 bitové file–handle, kterou klient předává vevšech požadavcích serveru. Po úspěšně autentizaci klient od serveru obdrží 32 bitovýidentifikátor uživatele, kterým při další komunikaci prokazuje uživatele serveru, a iniciálnífile–handle. Veškerá bezpečnost tedy závisí na těchto identifikátorech.

Protokol nabízí několik úrovní zabezpečení komunikace. Nejvyšší úroveň kryptogra-ficky podepisuje síťové zprávy, aby nemohlo dojít k modifikaci packetů a tím získánípřístupu neoprávněným uživatelem. Obsah zpráv šifrovaný není, může tedy dojít k únikudat. Systém je však navržen pro použití v lokálních sítích, které s tímto faktorem přílišnepočítají.

Cesty souborového systému identifikují objekt v rámci celého systému. Cesta seskládá ze tří komponent: jména serveru (<server>), jména svazku <volume> a cesty<path> v rámci svazku:

<server>/<volume>:<path>

Přístup k objektům je kontrolován systémem listů ACL. Práva ACL jsou hierarchickyděděna do podadresářů. Pomocí tzv. inheritance mask lze modifikovat, která práva bu-dou do podadresáře děděna. Každá položka ACL může nastavovat celkem osm příznakůoprávnění:

� Supervisor: povoluje veškerá práva k objektu.

� Read: dovoluje soubor otevřít, číst a spouštět.

� Write: povolení zápisu.

� Create: vytváření nových objektů v adresáři.

� Erase: povolení mazání objektů.

� Modify: dovoluje modifikovat atributy objektu (čas, datum atd.).

� File scan: povolí vypsat obsah adresáře.

� Access: právo modifikovat přístupová práva.

Krom standardních objektů souboru a adresáře Novell nabízí též vytváření pevnýchodkazů. Odkazy jsou implementovány seznamem alternativních jmen u mateřského sou-boru. Novell též nabízí obnovení smazaných souborů. S touto vlastností se setkáme u má-lokterého souborového systému.

– 73 –

Server též dokáže komprimovat soubory pro úsporu místa na disku. Pro ušetření místana disku systém dovoluje též přesunout data na sekundární diskové médium. U malýchsouborů souborový systém dovoluje ukládání více souborů v jednom bloku, tzv. děleníbloků.

Pro zvýšenou bezpečnost zvláště důležitých dat systém nabízí ochranu sledovánímtransakcí, tzv. systém TTS. Princip je následující: při otevření souboru se vytvoří jehozáložní kopie. Pokud práce se souborem skončí úspěšně, změny se uloží do původníhosouboru a kopie se zruší. Pokud dojde během operace se souborem k havárii, systémobnoví soubor ze záložní kopie a případné poškozené změny se takto zruší.

Jelikož klienty mohou běžet na různých operačních systémech, Novell nabízí vytvořitvíce jmenných prostorů, pro každý systém jiný. Například pro DOS jmenný prostor s krát-kými jmény, pro UNIX jmenný prostor s UNIXovou maskou přístupových práv, nebo proOS/2 či MAC. U každého objektu je uloženo jméno a atributy pro každý podporovanýjmenný prostor.

Novell u každého souboru dovoluje nastavit širokou paletu atributů [74]. Krom čtyřechznámých atributů operačního systému DOS archive, hidden, read only a systempřichází s novými atributy:

� Delete inhibit: zabraňuje smazání objektu.

� Indexed: automaticky nastavovaný atribut, pokud soubor přesáhne určitou veli-kost, Novell soubor pro zrychlení přístupu zindexuje.

� Purge: objekt bude po smazání fyzicky zrušen a nepůjde již obnovit.

� Rename inhibit: zabraňuje přejmenování objektu.

� Read/Write: povoluje modifikaci a smazání souboru.

� Shareable: dovoluje sdílení souboru více procesy.

� Execute only: se souborem nelze provádět jiné operace než spuštění.

� Can’t compress: automaticky nastavovaný atribut zamezující kompresi souboru.

� Compressed: soubor byl zkomprimován.

� Don’t compress: zabraňuje soubor komprimovat.

� Immediate compress: vynutí okamžitou komprimaci souboru.

� Don’t migrate: zakáže přesunutí souboru na sekundární diskové médium.

� Migrated: automaticky nastavovaný atribut značící uložení souboru na sekun-dárním médiu.

� Don’t suballocate: zabrání dělení bloků souboru.

� Transactional: zapnutí ochrany souboru TTS.

– 74 –

10. Výsledky měřeníV této kapitole uvedeme výsledky měření jednotlivých souborových systémů. Nejprve

uvedeme grafy s naměřenými veličinami během testů v běžných podmínkách a poté budounásledovat výsledky z měření za nepříznivých podmínek.

10.1 Měření v běžných podmínkách

0

5000

10000

15000

20000

25000

frer

ead

frea

d

frew

rite

fwrit

e

strid

e re

ad

reco

rd r

ewrit

e

back

war

d re

ad

rand

writ

e

rand

read

rere

ad

read

rew

rite

writ

e

kB/s

ec

Iozone

NFSSFS

NFS4CIFSAFS

Novell

Graf 1: Srovnání rychlostí jednotlivých operací.

0

10

20

30

40

50

60

70

80

90

100

frer

ead

frea

d

frew

rite

fwrit

e

strid

e re

ad

reco

rd r

ewrit

e

back

war

d re

ad

rand

writ

e

rand

read

rere

ad

read

rew

rite

writ

e

% C

PU

Iozone

NFSSFS

NFS4CIFSAFS

Novell

Graf 2: Srovnání vytížení CPU klientu souborovým systémem.

– 75 –

Na grafu 1 vidíme výsledky testu Iozone při práci s velmi velkými soubory, tedys eliminovaným vlivem page cache Linuxu. Na vodorovné ose jsou uvedeny jednotlivéměřené operace, na svislé ose je vynesena střední propustnost operace v kilobytech zasekundu.

Graf 2 zobrazuje zatížení procesoru na klientském stroji. Na vodorovné ose jsou opětuvedeny jednotlivé operace, svislá osa značí zatížení procesoru klientu v procentech.

Z prvního grafu můžeme vidět, že při zápisech jsou nejrychlejší systémy NFS a NFS4,ve čtení však vyniká protokol SMB/CIFS. Na obou grafech výrazně vyniká AFS u operacerecord rewrite neboli přepisování stejného místa souboru. Tato špička je způsobenaklientskou cache AFS, jak lze vidět i z grafu zatížení CPU. Dle [59] klientská cache na AFSzachytí přes 95% požadavků. Systémy vycházející z NFS při této operaci vykazují nejhoršírychlost, systém SMB/CIFS je druhý nejlepší, což je pravděpodobně také způsobenocache.

Přestože SFS používá kryptovanou komunikaci, z grafu 2 plyne, že zatížení procesorušifrováním je minimální. Ovšem tento souborový systém také dopadl jako nejhorší.

0

50

100

150

200

250

300

350

400

tarfinddiffcopycat

Tes

t dur

atio

n (s

econ

ds)

Test duration comparison

NFSSFS

NFS4CIFSAFS

NovellKlient local

Server local

Graf 3: Srovnání doby trvání testů reálné zátěže.

Na grafu 3 můžeme vidět porovnání výsledků jednotlivých reálných testů. Na svisléose je uvedena doba trvání testu v sekundách, na vodorovné ose jsou uvedeny jednotlivétesty reálné zátěže. Pro zajímavost jsou v grafu uvedeny i výsledky měření pro lokálnísouborový systém klientu a serveru na systému Linux používajícím souborový systémEXT2.

– 76 –

Téměř ve všech testech dopadl systém SFS nejhůře. Pro práci s velkými soubory jsouideální systémy NFS a SMB/CIFS. Z testu Diff má nejlepší výsledky Novell, neboť serverukládá většinu metadat souborového systému v operační paměti. Podobný výsledek byměl mít Novell též u testu Find, ale zde dopadá jako jeden z nejhorších. Podíváme-lise na graf 7, okamžitě vidíme příčinu. Systém Novell při čtení obsahu adresářů používávelice krátké packety, čímž velmi zatěžuje síť a zpomaluje operaci.

Následují grafy zátěže sítě a střední velikosti packetu. Na svislé ose je počet přenese-ných bytů, respektive velikost packetu v bytech. Levá část grafů zobrazuje příchozí provozna klientu, pravá část zobrazuje odchozí provoz.

0

2e+07

4e+07

6e+07

8e+07

1e+08

1.2e+08

1.4e+08

1.6e+08

1.8e+08

CAT outCAT in

Byt

es tr

ansf

ered

Cat

NFSSFS

NFS4CIFSAFS

Novell

0

200

400

600

800

1000

1200

1400

1600

CAT outCAT in

Pac

ket s

ize

Cat

NFSSFS

NFS4CIFSAFS

Novell

Graf 4: Síťová zátěž a velikost packetu při testu Cat.

0

2e+07

4e+07

6e+07

8e+07

1e+08

1.2e+08

1.4e+08

1.6e+08

1.8e+08

COPY outCOPY in

Byt

es tr

ansf

ered

Copy

NFSSFS

NFS4CIFSAFS

Novell

0

200

400

600

800

1000

1200

1400

1600

COPY outCOPY in

Pac

ket s

ize

Copy

NFSSFS

NFS4CIFSAFS

Novell

Graf 5: Síťová zátěž a velikost packetu při testu Copy.

0

2e+07

4e+07

6e+07

8e+07

1e+08

1.2e+08

1.4e+08

1.6e+08

DIFF outDIFF in

Byt

es tr

ansf

ered

Diff

NFSSFS

NFS4CIFSAFS

Novell

0

200

400

600

800

1000

1200

1400

DIFF outDIFF in

Pac

ket s

ize

Diff

NFSSFS

NFS4CIFSAFS

Novell

Graf 6: Síťová zátěž a velikost packetu při testu Diff.

– 77 –

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

FIND outFIND in

Byt

es tr

ansf

ered

Find

NFSSFS

NFS4CIFSAFS

Novell

0

100

200

300

400

500

600

700

800

FIND outFIND in

Pac

ket s

ize

Find

NFSSFS

NFS4CIFSAFS

Novell

Graf 7: Síťová zátěž a velikost packetu při testu Find.

0

1e+07

2e+07

3e+07

4e+07

5e+07

6e+07

7e+07

TAR outTAR in

Byt

es tr

ansf

ered

Tar

NFSSFS

NFS4CIFSAFS

Novell

0

100

200

300

400

500

600

700

800

900

1000

TAR outTAR in

Pac

ket s

ize

Tar

NFSSFS

NFS4CIFSAFS

Novell

Graf 8: Síťová zátěž a velikost packetu při testu Tar.

V testech Cat a Copy všechny souborové systémy přenášely přibližně stejný objemdat. Podrobnější srovnání využití sítě jednotlivými systémy nalezneme dále v kapitoleRežie protokolů. U testu Find vidíme, že systémy AFS a SMB se snaží přenášet obsahyadresářů v co největších packetech, kdežto Novell používá malé packety, které zbytečnězatěžují síť.

10.2 Chování za nepříznivých podmínek

Tabulka 2 zobrazuje chování souborových systémů při podmínkách chybové sítě. Hod-noty jsou naměřeny programem Iozone a zobrazují rychlosti operací čtení, opakovanéčtení, zápis a opakovaný zápis, hodnoty jsou uvedeny v kB/s. U každého souborovéhosystému jsou uvedeny tři řádky, první řádek zobrazuje hodnoty naměřené na nechybovélince, druhý zobrazuje chování při 1% chybovosti a třetí při 10% chybovosti. Srovnání jeuvedeno spíše pro zajímavost.

Vysoké hodnoty v řádech desítek megabytů za sekundu jsou způsobeny zkreslenímvlivem page cache Linuxu. Prázdné řádky znamenají, že test do jedné hodiny nedoběhl.Je vidět, že souborové systémy SMB/CIFS a AFS nejsou určeny pro příliš chybové linky.

AFS při 10% chybovosti linky bylo naprosto nepoužitelné i po vypnutí ztrátovostia klient bylo nutno rebootovat. Klient Samba při 10% ztrátovosti ohlásil nedostupnostserveru a operace byla přerušena. NFS hlásilo nedostupnost serveru, ale po čase opětkomunikaci obnovilo a s minimální rychlostí přenášelo data.

– 78 –

write rewrite read reread

NFS (0%) 1710 1068 94995 97269NFS (1%) 499 1662 95291 97158NFS (10%) 3 4 94447 96713

SFS (0%) 595 859 96117 97112SFS (1%) 59 1479 95779 97098SFS (10%) 77 77 96141 97542

NFS4 (0%) 999 1387 1057 5313NFS4 (1%) 3067 45054 874 89577NFS4 (10%) 39854 44942 73 89573

CIFS (0%) 896 904 915 2669CIFS (1%) 68 37 66 517CIFS (10%)

AFS (0%) 771 898 2477 2234AFS (1%) 705 1163 2518 3432AFS (10%)

Tabulka 2: Chování souborových systémů při chybovosti 0%, 1% a 10%

Výkon jednotlivých souborových systémů v podmínkách omezené šířky pásma a la-tence shrnují následující tabulky. Sloupce označují rychlost přenosové linky v kilobitechza sekundu, řádky udávají round–trip linky. Hodnoty v tabulce jsou udány v kB/s, leváhodnota značí rychlost zápisu, pravá rychlost čtení.

Chování souborových systémů je ovlivněno zejména použitým transportním protoko-lem a protokolem RPC. V zásadě lze systémy rozdělit do tří kategorií. V první skupinějsou systémy odolné vůči zpoždění linky, rychlost přenosu závisí lineárně na rychlosti sítěa blíží se teoretické maximální přenosové kapacitě linky. Sem patří škálovatelné systémy,které je možno provozovat na rychlých sítích LAN i na modemových linkách. V druhéskupině je rychlost operací závislá zejména na latenci, což je většinou způsobeno mecha-nismem request–response, kdy klient vyšle žádost a dokud nedostane odpověď od serveru,nepokračuje v operaci. Třetí, nejhorší, skupina zahrnuje systémy, u nichž propustnost ope-rací s klesající rychlostí sítě nebo rostoucím zpožděním nelineárně klesá. Tyto systémyjsou na pomalých linkách (například modemových) prakticky nepoužitelné.

64kbps 128kbps 512kbps 1024kbps

10ms 7.773/0.765 15.284/2.045 61.207/11.580 120.117/30.183

100ms 1.732/2.090 8.269/2.035 58.514/10.925 102.801/31.359

500ms 1.658/2.036 14.456/2.025 49.311/10.354 69.817/30.183

Tabulka 3: Chování NFS na lince s latencí a omezenou šířkou pásma.

U NFS se zvyšující latencí rapidně klesá rychlost zápisu. Rychlost čtení na zpožděnínezávisí, ale je podstatně nižší než teoretická propustnost linky. NFS lze zařadit do třetíkategorie, neboť již při rychlosti 128kbps již téměř nebylo použitelné pro čtení. Dispro-porce mezi čtením a zápisem může být způsobena nevhodými parametry čekání, neboť

– 79 –

během testů NFS klient neustále hlásil nedostupnost serveru.


10ms 7.609/7.605 10.832/15.256 16.313/60.867 54.012/120.639

100ms 7.591/7.618 9.624/8.488 45.123/59.366 102.628/107.599

500ms 7.321/7.554 13.839/13.860 25.171/28.004 28.610/20.306

Tabulka 4: Chování SFS na lince s latencí a omezenou šířkou pásma.

SFS se ve ztížených podmínkách chovalo trochu lépe než NFS, kapacita 64kbps linkybyla téměř celá využita pro přenos dat. Disproporce mezi čtením a zápisem není tolikvelká jako u NFS, na rozdíl od NFS byla rychlejší operace čtení. U vyšších rychlostí lzepozorovat zpomalení čtení v závislosti na latenci.


10ms 7.592/7.596 15.256/29.290 61.047/54.289 121.366/121.792

100ms 7.548/9.891 15.144/15.119 37.184/36.828 37.161/49.149

500ms 6.331/6.365 7.704/7.787 7.715/7.790 7.716/7.763

Tabulka 5: Chování CIFS na lince se zpožděním a omezenou šířkou pásma.

U protokolu SMB/CIFS z tabulky 5 plyne očividná závislost rychlosti operací nazpoždění linky, která je pravděpodobně způsobena použitím protokolu RPC, kdy klientpo odeslání požadavku čeká na odpověď serveru. Až u opravdu nízké rychlosti 64kbpsvynikne omezení dané propustností linky. Rychlosti čtení i zápisu jsou stejné, z čehož lzeusuzovat symetrický charakter protokolu, kdy komunikace a potvrzování při čtení i zápisuprobíhá stejným způsobem.


10ms 7.72/1417.64 15.57/1130.79 62.15/16399.74 64.66/1266.89

100ms 7.71/5749.35 15.45/5394.04 60.30/1382.93 65.67/3351.90

500ms 7.64/2103.87 15.13/1891.17 55.04/1304.97 70.35/5836.78

Tabulka 6: Chování AFS na lince s omezenou šířkou pásma a latencí.

U systému AFS lze na první pohled z naměřených hodnot vidět účinky lokální cacheprojevující se při čtení. Návrat z funkce write() proběhl téměř okamžitě, při zavolaníclose() byl obsah cache odeslán na server. Rychlost zápisu závisí na zpoždění sítě mi-nimálně, naměřené hodnoty rychlostí zápisů se velice blíží teoretické maximální propust-nosti té které linky. Návrh protokolu zajišťuje minimální režii, AFS lze tedy provozovati na pomalých linkách.

– 80 –


10ms 7.646/7.649 15.179/15.385 58.204/61.391 116.576/115.296

100ms 7.601/7.676 15.095/15.314 57.803/57.147 107.147/106.284

500ms 7.399/7.587 14.279/14.935 44.958/45.913 54.200/47.158

Tabulka 7: Chování NFS4 na lince s omezenou šířkou pásma a latencí.

U NFS4 můžeme pozorovat mírnou závislost rychlosti na latenci, avšak u nízkýchpřenosových rychlostí sítě tato závislost téměř není znatelná. Vytížení přenosové linkynení úplně maximální, přesto můžeme zařadit NFS4 do první kategorie, neboť ho lzeprovozovat na modemových linkách bez ohledu na jejich zpoždění.


NFS 457.12 288.85 325.15 331.36

SFS 233.65 226.16 171.52 199.67

NFS4 1102.52 721.63 299.34 331.32

CIFS 509.89 312.14 1268.06 28968.53

AFS 271.43 84.33 276.46 244.19

Tabulka 8: Srovnání systémů při paralelní zátěži serveru.


NFS 584.17 480.50 465.83 634.00

SFS 213.00 259.17 69.33 74.33

NFS4 614.50 613.17 448.33 466.16

CIFS 476.33 559.67 773.5 788.5

AFS 274.00 232.00 230.00 216.33

Tabulka 9: Teoretické šestinové hodnoty rychlostí s jediným klientem.

V tabulce 8 vidíme naměřené rychlosti operací čtení, opakovaného čtení, zápisu svytvořením souboru a opakovaného zápisu do souboru při měření šesti pracujících procesůna třech klientech. V tabulce 9 jsou pro srovnání vypočítány šestinové hodnoty rychlostízměřených s jediným procesem. Pokud je systém dobře škálovatelný, měly by teoretickéhodnoty odpovídat hodnotám naměřeným při zátěži šesti procesy, neboť pokud je přizátěži jedním klientem limitace průtoku dat vymezena hardwarem serveru nebo sítí, přišestinásobné zátěži by měl být teoretický průtok šestinovvý.

Porovnáme-li obě tabulky, můžeme už při takto nízkém počtu klientů najít limitaceněkterých systémů. U NFS jsou naměřené hodnoty nižší než teoreticky spočítané, což zna-mená, že úzké místo je v software serveru. U NFS4 naopak naměřené hodnoty při zápisujsou vyšší než teoretické, jeden klient NFS4 tedy není schopen plně vytížit přenosovoulinku. Hodnoty čtení u CIFS jsou zkresleny paměťovou cache. AFS se ukázalo jako šká-

– 81 –

lovatelné, neboť teoretické hodnoty poměrně přesně odpovídají hodnotám naměřeným.Úzké místo u AFS tedy spočívá v síti.

10.3 Režie protokolů

Režie protokolů byla měřena na základě dat získaných z testů Copy a Cat. Běhemtěchto testů byl změřen počet přenesených bytů skrz síťovou kartu v obou směrech, kterýoznačíme jako inflow (data přenesená ze serveru na klient) outflow (data přenesenáz klientu na server). Označíme-li velikost přenášeného souboru v bytech jako size, můžemerežii protokolu overhead vyjádřit jako

overhead = 100 � (1� inflow

size)

respektive

overhead = 100 � (1� outflow

size)

Dopředný směr v tabulkách označuje směr komunikace, ve kterém byla přenášenadata, ve zpětném směru se reálná data nepřenáší, přenáší se pouze režie (například po-tvrzování). Naměřené hodnoty odpovídají procentuálnímu poměru režijních dat protokoluk přenášeným datům. Tedy například hodnota 1% odpovídá situaci, kdy pro přenesení1000 B dat protokol po síti přenese 1010 B v dopředném směru a 10 B ve zpětném směru.

Hodnota zahrnuje nejen režii samotného souborového systému, ale též režii použitéhotransportního protokolu. Pro příklad uvažujme dva totožné protokoly, jeden používajícíkrátké packety a druhý používající packety s maximální možnou délkou. Srovnáme-li tytodva protokoly, režie druhého protokolu bude nižší než režie protokolu prvního.

Dopředný směr Zpětný směr

NFS 3.421% 1.068%

SFS 8.452% 1.092%

NFS4 1.523% 2.971%

SMB 4.608% 3.885%

AFS 3.130% 3.870%

Novell 1.420% 2.968%

Tabulka 10: Režie během testu Cat.

Tabulka 10 vyjadřuje režii čtení ze souboru. Největší režii vykazuje SFS, které veške-rou komunikaci kryptuje. NFS používá jednoduchý protokol, proto vyžaduje minimálnízpětnou komunikaci. SMB i AFS potřebují poměrně silný zpětný kanál pro potvrzování.

– 82 –

Dopředný směr Zpětný směr

NFS 3.650% 1.333%

SFS 5.790% 4.237%

NFS4 5.116% 2.564%

SMB 5.348% 3.907%

AFS 2.461% 2.453%

Novell 5.009% 2.561%

Tabulka 11: Režie během testu Copy.

Porovnáme-li tabulku 10 a 11, vidíme nápadnou podobnost hodnot u protokolů NFS4a Novell.

– 83 –

11. Srovnání souborových systémů

NFS klient během testování na uvedených operačních systémech vykazoval problémyběhem nedostupnosti serveru. V případě, že došlo k pádu serveru nebo k rozpojení sítěmezi klientem a serverem, všechny NFS operace zavolané z aplikace zůstaly zabloko-vány v jádře, dokud nedošlo k obnovení spojení, a to i po vypršení doby všech časovýchintervalů. Důvodem tohoto chování je chybná implementace klientu v jádře Linuxu.

Mezi přednosti NFS patří jednoduchý lehký design, s nímž souvisí rychost, malénároky na systém a jednoduchá implementace. Jeho hlavní chybou je nedostatečná bez-pečnost. NFS je ve světě UNIXových operačních systémů široce rozšířeným standardem,který nalezne podporu prakticky na všech platformách. NFS najde ideální použití proanonymní sdílení velkého množství necitlivých dat na malých lokálních sítích.

SFS lze tedy použít jako bezpečnou avšak pomalejší nadstavbu systému NFS. Jehovýhoda spočívá zejména v možnosti připojení systému libovolným uživatelem. Myšlenkavytvoření globálního bezpečného systému bez nutnosti užití certifikačních autorit je za-jímavá a přínosná.

Během zkoumání SFS byla k dispozici verze 0.6 a verze 0.7 byla ve vývoji. Při pře-chodu na novou verzi se kompletně změnil autentizační protokol, nový klient je zpětněkompatibilní se starým serverem, ale opačná kompatibilita nefunguje. S novou verzí ser-veru je možné nabízet služby v protokolu 0.6 i 0.7. Přestože autoři označují SFS jako alphaverzi a systém je stále ve vývoji, během testování se souborový systém choval stabilně.Zotavení z pádu serveru nebo síťového spojení je vyřešeno lépe než u NFS, při rozpadu ko-munikace mezi klientem a serverem je možné operace přerušit a systém odpojit, nedojdek zablokování klientu v jádře operačního systému.

Přínosem z bezpečnostního hlediska je přístup do systému jako samostatný uživatel,nutnost spuštění speciálního příkazu k zalogování není příjemná a znemožňuje používáníSFS pro domovské adresáře uživatelů. Navíc systém nelze připojovat příkazem mount neboz /etc/fstab. Použití pro domovské adresáře by se dalo docílit napsáním PAM modulu,který by při zalogování uživatele do systému automaticky připojil například uživatelůvdomovský adresář. Celkový návrh komunikace, kdy se uživatel loguje k serveru a nenízapotřebí žádných dalších autorit k ověření uživatelovy totožnosti, je pěkný a myšlenkasamocertifikujících cest k souborům se jeví jako velmi dobrá. SFS nabízí též anonymnípřístup vhodný pro sdílení veřejných dat.

Rychlost souborového systému je oproti NFS přibližně poloviční, ovšem SFS je navr-ženo jako velmi bezpečné. Sémantika SFS odpovídá UNIXovému souborovému systémus drobnými odlišnostmi způsobenými NFS základem. Velkým nedostatkem je chybějícídatová cache na klientské straně, která by podstatně zvýšila výkon prováděných operací.

NFS4 v linuxovém kernelu se stále velice intenzivně vyvíjí, ještě nenabízí všechnyvlastnosti a funkcionality protokolu a není stabilní, tudíž ho nelze nasadit do provozníhosystému. Důkazem může být fakt, že během výzkumu nebyla k disposici provozuschopnáverze, na níž by bylo možno ozkoušet alespoň základní funkcionalitu, až krátce předdokončením práce byl uvolněn kód v jádře 2.5.66, který bylo možno ozkoušet. Předchozí

– 84 –

verze byly nestabilní, nefunkční a během testování nezřídka docházelo k pádům celéhosystému. Během testů na NFS4 v jádře 2.5.66 operace selhávaly z důvodu chyb v kódu,chyb XDR, rozpadů komunikace a dalších. Na stránkách projektu [22] autoři nabízí údajněstabilní verzi pro jádro 2.4.18, její funkčnost však z časových důvodů ž nebylo možnoozkoušet.

NFS4 mělo problémy se zotavení z pádu serveru nebo rozpadu síťového spojení, alezotavení probíhalo lépe než u NFS 3. Došlo-li k rozpadu komunikace, operace se zablo-kovala v jádře a uživatel byl obtěžován varovnými hláškami, ale po vypršení timeoutuoperace skončila s chybou a bylo možno program ukončit.

Oproti předchozím verzím NFS4 přináší mnoho změn a řešení nedostatků verzí před-chozích, jeho rychlost je srovnatelná s předchozími verzemi. Z hlediska návrhu NFS4přináší spoustu zajímavých myšlenek, avšak chybí jejich úplná a funkční implementace.

Nejrozšířenějším SMB serverem ve světě UNIXových operačních systémů se stalaSamba, která poskytuje kvalitní server, avšak ještě se autorům bohužel nepodařilo vy-tvořit stejně plnohodnotný klient přenositelný na většinu UNIXů. Balík Samba nabízíjako svoji součást přenositelný smbclient s jednoduchým textovým rozhraním s příkazo-vou řádkou podobným textovému FTP klientu. Klient poskytuje nejzákladnější operacepro přenos souborů, je snadno rozšiřitelný a existuje pro něj několik grafických nadstaveb.Svými vlastnostmi se též hodí pro automatizované nasazení, jako je například automa-tické zálohování, monitoring, nebo použití v instalačních skriptech.

Operační systémy Linux a FreeBSD zatím jako jediné z UNIXových operačních sys-témů ve svém jádře integrují SMB klient nazvaný smbfs. Klient poskytuje plně transpa-rentní přístup na vzdálený server, sdílené prostředky nabízené serverem se připojují doadresářové struktury klientu pomocí příkazu smbmount. Po připojení vzdáleného serveruzůstane smbmount běžet na pozadí jako daemon, který vykonává práci klientu. smbfs bo-hužel nabízí jen málo vymožeností protokolu SMB, autentizaci je nutno provádět běhempřipojování systému.

Široké použití AFS naráží na problém se jmenným prostorem. Adresář /afs obsa-huje odkazy na všechny AFS buňky po celém světě. Procházení tohoto adresáře je z dů-vodu počtu buněk zdlouhavé, neboť klient musí postupně kontaktovat AFS servery každéz buněk. Přidání nové buňky je nutno provést manuálním zásahem do konfigurace všechbuněk, které mají mít přístup do nové buňky. Návrh AFS by měl s těmito problémy dobudoucnosti počítat a snažit se je vyřešit. Jedním z možných řešení by bylo zavedeníhierarchického systému podobnému DNS.

Jak bylo zjištěno, systém AFS patří k pomalejším systémům, ale jeho návrh je kom-plexní, robustní a bezpečný, proto je určen spíše pro velmi rozsáhlé sítě WAN. Přínosemje též rozšířenost na mnoha platformách.

Novell NetWare je vhodný spíše jako proprietární řešení pro menší podniky. Jehonevýhodou je zejména uzavřenost a komerční dostupnost.

– 85 –

NFS SFS NFS4 CIFS AFS Novell

Klient na OS U,W L,B,S L W,U U,W L,W,X,N

Server na OS U,W L,B,S L W,U U,W N,X

Free implementaceklientu(K), serveru(S)

K,S K,S K,S K,S K,S K

Stav vývoje:stabilní (S)vyvíjí se(V)

S V V S S S

Veřejná dokumentacek protokolu

ano ano ano ano 3) ano ne

Architektura:klient–server(CS)peer–to–peer(PP)

CS CS CS PP CS CS

Klient v kernelu(K)userlandu(U)

K,U U 4) K U U U

Server v kernelu(K)userlandu(U)

K,U U 5) K U,K U K

Tabulka 12: Základní vlastnosti souborových systémů.

Tabulka 12 shrnuje základní vlastnosti souborových systémů. Řádky „Klient na OSÿa „Server na OSÿ označují operační systémy, pro něž lze nalézt klient, respektive server.Jednotlivá písmena označují:

W WindowsL LinuxB BSD (OpenBSD nebo FreeBSD)S SolarisN NovellU UNIX obecněX UnixWare

Poslední dva řádky popisují, zda existuje implementace klientu, respektive serveruv jádře, nebo v uživatelském režimu. Systémy, které mají uvedeny obě varianty jsouna některých platformách implementovány v kernelu a na některých v userlandu. Kli-ent i server systému CIFS jsou součástí jádra operačního systému Windows, na UNIXuběží server i klient v uživatelském režimu. Souborový systém Novell je součástí jádraoperačního systému NetWare.

3) Dokumentace poslední verze protokolu je proprietární.4) Vyžaduje podporu NFS v kernelu.5) Vyžaduje podporu NFS v kernelu.

– 86 –


Přenosové protokoly T T T I,N,T T I,T

Protokol v TCP/IPTCP(T), UDP(U)

T,U T T T,U U U

Lze firewallovat ne ano ano ano ne ne

Lze tunelovat ne ano ano ano ne ne

Tabulka 13: Srovnání síťových vlastností.

Tabulka 13 shrnuje důležité síťové vlastnosti jednotlivých systémů. Zkratky přenoso-vých protokolů znamenají:

T TCP/IPI IPX/SPXN NetBIOS/NetBEUI

Dovoluje-li některý systém běžet na více transportních protokolech, jsou uvedenyvšechny. Všechny systémy podporují TCP/IP, proto je v tabulce uvedeno též, zda ko-munikace probíhá po TCP, nebo po UDP. NFS ve verzi 3 dovoluje vybrat transportníprotokol. Systém CIFS používá oba dva. AFS samotné komunikuje pouze po protokoluUDP, avšak vyžaduje časovou synchronisaci protokolem NTP, který používá TCP.


Lze transparentněpřipojit

ano ne ano ano ne ano

Lze připojit pod běžnýmuživatelem

ne ano ne ne ano ne 6)

Nabízí UNIX přístupovápráva

ano ano ano ano ano ano

Nabízí ACL ne ne ano ano ano ano

Datová cache na klientu:paměť(M), disk(D)

ne ne M M M,D ne 7)

Vyžaduje synchronisaciuživatelských ID

ano 8) ne ne ne ne ne

Tabulka 14: Vlastnosti souborového systému.

Poslední dva řádky tabulky 13 udávají, zda lze protokol propustit skrz firewall či tu-nelovat. Schopnost propustit skrz firewall je nutnou podmínkou k tunelování. NFS nelzepropustit skrz firewall, neboť nemá pevně definované porty, které používá ke komunikaci.Propustnost skrz firewall u AFS nebyla testována, ale z charakteru použitého bezpeč-

6) Na testovaném klientu v Linuxu.7) Na testovaném klientu v Linuxu.8) Většina implementací však synchronisaci nepodporuje.

– 87 –

nostního systému Kerberos vyplývá, že by propouštění skrz firewall bylo obtížné. SystémNovell je určen pro nasazení v lokální síti, proto není určen pro tunelování ani propouštěnískrz firewall.

V tabulce 14 najdeme shrnuté vlastnosti souborového systému. Řádek „Lze připojitpod běžným uživatelemÿ popisuje, zda lze souborový systém na UNIXu připojit beznutnosti administrátorských práv. Systém AFS musí nakonfigurovat administrátor, avšakuživatelé po zalogování mohou se systémem běžně pracovat.

V řádku „Vyžaduje synchronisaci UIDÿ najdeme, zda systém vyžaduje externí syn-chronisaci uživatelských databází (hodnota „anoÿ), nebo zda umí identifikátory uživatelůsám překládat (hodnota „neÿ).


Podporuje replikaci dat ne ne ano ano ano ne

Podporuje migraci dat ne ne ano ano ano ne

Vlastní souborovýsystém

ne ne ne ne ano ano

Tabulka 15: Vlastnosti serveru.

Tabulka 15 shrnuje důležité vlastnosti serveru. Systém NFS4 je navržen s podporoureplikace a migrace dat, obsahuje mechanismus předávání souborů na jiný server. Spe-cifikace však nepopisuje konkrétní protokol komunikace mezi servery. Novell umožňujepouze vytvořit cluster několika serverů, které navenek vystupují jako jeden server, alesdílejí společné diskové pole.


Kryptovaný přenos hesel ne ano ano ano ano ano

Kryptovaný přenos dat ne ano ano ne ano ne

Kryptograficky podepiso-vaná komunikace

ne ano ano ano ano ano

Autentizace k serveru(S)systému(N)

S S S S,N N S,N

Vyžaduje časovousynchronisaci

ne ne ne ne ano ne

Anonymní přístup ano ano ano ano ano ano

Tabulka 16: Bezpečnostní aspekty.

V tabulce 16 najdeme shrnuté důležité bezpečnostní aspekty jednotlivých souboro-vých systémů. Hodnoty vypovídají, zda daný systém konkrétní funkci (například ano-nymní přístup) podporuje. Některé vlastnosti pochopitelně lze konfigurací vypnout.

Autentizace k systému znamená, že uživatel se neautentizuje ke konkrétnímu soubo-rovému serveru, ale k systému jako celku. V praxi se uživatel většinou spojuje s autenti-

– 88 –

začním serverem, od kterého obdrží token, který ho pak opravňuje přistupovat ke všemserverům systému, aniž by se musel ke každému autentizovat heslem zvlášť. SystémyCIFS i Novell dovolují obě varianty, záleží na verzi protokolu.

Jediný systém AFS vyžaduje časovou synchronizaci klientů se serverem, kterou vy-žaduje systém Kerberos. Anonymní přístup v systému Novell a AFS lze vytvořit pomocíuživatele bez hesla.

– 89 –

12. ZávěrCílem této práce bylo srovnat uvedené souborové systémy v rozličných podmínkách

a srovnat jejich chování i teoretické návrhy, výhody i nedostatky.

Jak jsme měli možnost zjistit, tak neexistuje ideální souborový systém, který by bylve všech vlastnostech nejlepší, byl rychlý, bezpečný a zároveň přenositelný a škálovatelný,minimálně by zatěžoval síť i procesor, mohl být provozován na lokálních sítích, v roz-lehlých sítích i na modemových linkách. Neexistuje jednoznačně nejlepší systém, každýsystém je vhodný pro jiné nasazení v jiných podmínkách.

Kdybychom přesto měli vybrat vítěze, pak pro lokální a menší sítě by se jím stalsystém CIFS. Pro nasazení v náročném prostředí tisíců klientů by jednoznačně pro svourobustnost, bezpečnost a škálovatelnost vyhrál systém AFS, byť nepatří mezi nejrychlejší.

To ovšem neznamená, že ostatní systémy jsou zavrženíhodné. Naopak, přicházejí smnoha přínosnými myšlenkami. Jako příklad můžeme uvést systém NFS4, které přicházís velice zajímavým a propracovaným návrhem, jako příklad můžeme uvést jeho systémdelegace operací, univerzální atributový model nebo mechanismus leases. Taktéž samo-certifikující cesty systému SFS jsou podnětné.

Výsledky práce převážně potvrdily předpokládané chování souborových systémů,pouze systém AFS poněkud nepříznivě překvapil svojí rychlostí, která byla odhadovánavyšší. Během měření asi největší problémy činila page cache Linuxu, která nepříznivěovlivňovala výsledky.

Práce naplnila svůj cíl srovnání uvedených souborových systémů na linuxových klien-tech. Dobré by bylo srovnat různé implementace téhož systému (například různé servery)a též srovnat klienty na platformě Windows. Bohužel ale prostředí systému Windows nenípro testování a měření tolik příznivé jako platforma UNIX.

Z technických důvodů bohužel nebylo možno ozkoušet chování jednotlivých systémův prostředí středně velké sítě například s dvaceti až padesáti počítači, což je škoda.Případné další pokračování této práce by mohlo chování souborových systémů na tomtopoli prozkoumat.

Uvedené testy se snažily navodit zátěž systému přirozenými prostředky a tak se přiblí-žit reálné situaci z běžného provozu systému. Pro získání výsledků nejvíce odpovídajícíchrealitě by bylo nutno měřit chování na provozním systému, což z důvodu dostupnostinebylo možné a v praxi by bylo i velmi obtížně realizovatelné.

– 90 –

13. Literatura

[1] Bill Nowicki: NFS: Network File System Protocol Specification, Technical ReportRFC-1094, Sun Microsystems Inc., Network Working Group, March 1989

[2] Pawlowski, Juszczak, Staubach, Smith, Lebel, Hitz: NFS Version 3 Design andImplementation, USENIX Summer 1994 conference

[3] B. Callaghan, B. Pawlowski, P. Staubach: NFS Version 3 Protocol Specification,Technical Report RFC-1813, Sun Microsystems Inc., Network Working Group,June 1995

[4] S. Shepler & col.: NFS version 4 Protocol, Technical Report RFC-3010, NetworkAppliance Inc., Network Working Group, December 2000

[5] RPC: Remote Procedure Call Protocol Specification, Technical ReportRFC-1050, Sun Microsystems Inc., Network Working Group, April 1988

[6] RPC: Remote Procedure Call Protocol Specification Version 2, Technical ReportRFC-1057, Sun Microsystems Inc., Network Working Group, June 1988

[7] R. Srinivasan: RPC: Remote Procedure Call Protocol Specification Version 2,Technical Report RFC-1831, Sun Microsystems, Network Working Group,August 1995

[8] XDR: External Data Representation Standard, Technical Report RFC-1014, SunMicrosystems Inc., Network Working Group, June 1987

[9] R. Srinivasan: XDR: External Data Representation Standard, Technical ReportRFC-1832, Sun Microsystems, Network Working Group, August 1995

[10] Hal Stern: Managing NFS and NIS, 1992 O’Reilly & Associates, ISBN0-937175-75-7

[11] M. Eisler: NFS Version 2 and Version 3 Security Issues and the NFS Protocol’sUse of RPCSEC GSS and Kerberos V5, Technical Report RFC-2623, SunMicrosystems, Inc., June 1999

[12] E. Rescorla: Diffie-Hellman Key Agreement Method, Technical Report RFC-2631,RTFM Inc., June 1999

[13] S. P. Miller, B. C. Neuman, J. I. Schiller, J.H. Saltzer: Kerberos Authenticationand Authorization System, Section E.2.1, Project Athena Technical Plan, M.I.T.Project Athena, Cambridge, Massachusetts, December 1987

[14] Bill Bryant: Designing an Authentication System: a Dialogue in Four Scenes,Project Athena internal document, M.I.T., draft on February 1988

[15] http://www.unix.org/

[16] Brian Pawlowski & col.: The NFS Version 4 Protocol, SANE 2000

[17] Brent Callaghan: WebNFS Client Specification, Technical Report RFC-2054, SunMicrosystems Inc., Network Working Group, October 1996

[18] Brent Callaghan: WebNFS Server Specification, Technical Report RFC-2055,Sun Microsystems Inc., Network Working Group, October 1996

– 91 –

[19] M. Eisler, A. Chiu, L. Ling: RPCSEC GSS Protocol Specification, TechnicalReport RFC-2203, Sun Microsystems Inc., Network Working Group, September1997

[20] Mike Eisler: LIPKEY - A Low Infrastructure Public Key Mechanism UsingSPKM, Technical Report RFC-2847, Zambeel, Network Working Group, June2000

[21] J. Kohl, C. Neuman: The Kerberos Network Authentication Service (V5),Technical Report RFC-1510, Digital Equipment Corporation, Network WorkingGroup, September 1993

[22] http://www.citi.umich.edu/projects/nfsv4/

[23] M.L. Kazar, B. Leverett, et.al.: Decorum File System Architectural Overview,Proceedings of the USENIX Summer 1990 Conference

[24] R. Macklem: Not Quite NFS, Soft Cache Consistency for NFS, Proceedings ofthe USENIX Winter 1994 Conference

[25] http://www.fs.net/

[26] David Mazieres: SFS 0.7.1 Manual, http://www.fs.net/, 2002

[27] Thomas Wu: The SRP Authentication and Key Exchange System, TechnicalReport RFC-2945, Stanford University, Network Working Group, September 2000

[28] D. Mazieres, M. Kaminsky, M. F. Kaashoek, E. Witchel: Separating keymanagement from file system security, M.I.T. Laboratory for Computer Science,December 1999

[29] David Mazieres: Security and Decentralized Control in the SFS Global FileSystem, August 1997

[30] David Mazieres: Self-certifying File System, doctoral thesis, M.I.T. Departmentof Electrical Engineering and Computer Science, May 2000

[31] Niels Provos, David Mazieres: A Future-adaptable Password Scheme, Proceedingsof the 1999 USENIX, Freenix track (the on-line version), Monterey, CA, June1999, USENIX, http://www.usenix.org/events/usenix99/provos.html

[32] H.C. Williams: A Modification of the RSA Public-Key Encryption Procedure,IEEE Transactions on Information Theory, Vol. IT-26, No. 6, pp. 726-729, Nov1980

[33] B. Schneier: Description of a New Variable-Length Key, 64-Bit Block Cipher(Blowfish), Fast Software Encryption, Cambridge Security Workshop Proceedings(December 1993), Springer-Verlag, 1994, pp. 191-204

[34] Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: ConceptsAnd Methods, Technical Report RFC-1001, Network Working Group, March 1987

[35] Robert Eckstein, David Collier-Brown, Peter Kelly: Using Samba, November1999 O’Reilly&Associates, ISBN 1-56592-449-5

[36] Richard Sharpe: Just what is SMB?, October 2002, Samba Webpageshttp://samba.anu.edu.au/cifs/docs/what-is-smb.html

– 92 –

[37] Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: DetailedSpecifications, Technical Report RFC-1001, Network Working Group, March1987

[38] IBM PC Network Technical Reference No. 6322916, First Edition, September1984

[39] Paul J. Leach, Dilip C. Naik: A Common Internet File System (CIFS/1.0)Protocol, Preliminary Draft, Microsoft, Network Working Group, December 1997

[40] Paul J. Leach, Dilip C. Naik: CIFS/E Browser Protocol, Preliminary Draft,Microsoft, Network Working Group, January 1997

[41] Paul J. Leach, Dilip C. Naik: CIFS Domain Logon and Pass ThroughAuthentication, Preliminary Draft, Microsoft, Network Working Group, January1997

[42] Paul J. Leach, Dilip C. Naik: CIFS Printing Specification, Preliminary Draft,Microsoft, Network Working Group, January 1997

[43] Paul J. Leach, Dilip C. Naik: CIFS Remote Administration Protocol, PreliminaryDraft, Microsoft, Network Working Group, February 1997

[44] Microsoft Networks/OpenNET File Sharing Protocol, Intel Part Number 138446,Document Version 2.0, Microsoft Corporation & Intel Corporation, November1988

[45] Protocols for X/Open PC Networking: SMB, Version 2, Technical StandardC209, The Open Group, October 1992, ISBN 10872630-45-6

[46] IPC Mechanisms for SMB, Technical Standard C195, The Open Group,February 1992, ISBN 1-872630-28-6

[47] DCE 1.1: Remote Procedure Call, Technical Standard C706, The Open Group,August 1997

[48] Common Internet File System (CIFS) Technical Reference, Version: CIFS-TR1.0, CIFS Documentation Work Group, Storage Network Industry Association,March 2002

[49] Paul J. Leach: CIFS Security Considerations Update, Preliminary Draft,Microsoft, March 1997

[50] R. Rivest: The MD4 Message-Digest Algorithm, Technical Report RFC-1320,M.I.T. Laboratory for Computer Science and RSA Data Security, Inc., NetworkWorking Group, April 1992

[51] R. Rivest: The MD5 Message-Digest Algorithm, Technical Report RFC-1321,M.I.T. Laboratory for Computer Science and RSA Data Security, Inc., NetworkWorking Group, April 1992

[52] US National Bureau of Standards: Data Encryption Standard, FederalInformation Processing Standard (FIPS) Publication 46-3, October 1999

[53] US Department of Commerce: Secure Hash Standard, Federal InformationProcessing Standard (FIPS) Publication 180-1, April 1995

– 93 –

[54] Ledin ([email protected]): SMB/CIFS BY THE ROOT, Phrack#60, Volume 0x0b, Issue 0x3c, Phile #0x0b, http://www.phrack-dont-give-a-shit-about-dmca.org/show.php?p=60&a=11

[55] Jeff Donnelly: CIFS: UNIX Integration Issues, First CIFS Implementor’sWorkshop, August 1996

[56] Unicode Consortion: The Unicode Standard Version 3.0, Addison-Wesley,January 2000, ISBN 0-201-61633-5

[57] Alan O. Freier, Philip Karlton, Paul C. Kocher: The SSL Protocol Version 3.0,Internet Draft, Netscape Communications, November 1996

[58] Bridget Allison: CIFS Authentication and Security, Network Appliance Inc.,Technical Report TR-3020

[59] Edward R. Zayas: AFS-3 Programmer’s Reference: Architectural Overview,Version 1.0, Transarc Corporation, September 1991, FS-00-D160

[60] Edward R. Zayas: AFS-3 Programmer’s Reference: Specification for the RxRemote Procedure Call Facility, Version 1.2, Transarc Corporation, August 1991,FS-00-D164

[61] Edward R. Zayas: AFS-3 Programmer’s Reference: Volume Server/VolumeLocation Server Interface, Version 1.0, Transarc Corporation, August 1991,FS-00-D165

[62] Edward R. Zayas: AFS-3 Programmer’s Reference: BOS Server Interface,Version 1.0, Transarc Corporation, August 1991, FS-00-D161

[63] Edward R. Zayas: AFS-3 Programmer’s Reference: Authentication ServerInterface, Transarc Corporation, April 1993, FS-00-D166

[64] Edward R. Zayas: AFS-3 Programmer’s Reference: File Server/Cache ManagerInterface, Version 1.1, Transarc Corporation, August 1991, FS-00-D162

[65] Transarc Corporation: AFS Quick Beginnings,http://openafs.org/doc/index.htm, Version 3.6, Document NumberSC09-4560-00, First Edition, April 2000

[66] Edward R. Zayas: Administrative Cells: Proposal for Cooperative Andrew FileSystems, Information Technology Center internal document, Carnegie MellonUniversity, June 1987

[67] Edward R. Zayas, Craig Everhart: Design and Specification of the CellularAndrew Environment, Information Technology Center, Carnegi MellonUniversity, August 1988, CMU-ITC-070

[68] Paul Blackburn: AFS FAQ,http://www.angelfire.com/hi/plutonic/afs-faq.html, July 1998

[69] Michael L. Kazar: Ubik — A Library For Managing Ubiquitous Data, InformationTechnology Center, Carnegie Mellon University, Pittsburgh, PA, 1988

[70] Michael L. Kazar: Quorum Completion, Information Technology Center,Carnegie Mellon University, Pittsburgh, PA, 1988

– 94 –

[71] S. R. Kleinman: Vnodes: An Architecture for Multiple File System Types in SunUNIX, Conference Proceedings, 1986 Summer Usenix Technical Conference, pp.238–247, El Toro, CA, 1986

[72] Steve Lammert: The AFS 3.0 Backup System, LISA IV Conference Proceedings,Colorado Springs, Colorado, October 1990

[73] David L. Mills: Network Time Protocol (Version 3): Specification,Implementation and Analysis, Technical Report RFC-1305, University ofDelaware, Electrical Engineering Department, Network Working Group, March1992

[74] Oldřich Přichystal: Novell NetWare 6 podrobná příručka, Computer Press, Praha2002, ISBN 80-7226-625-X

[75] David Čečelský: Novell NetWare 5 kompendium, UNIS Publishing, 1999, ISBN80-86097-27-7

[76] http://snad.ncsl.nist.gov/itg/nistnet/

[77] http://www.iozone.org/

[78] http://gnuplot.sourceforge.net/

[79] Iozone Filesystem Benchmark, http://www.iozone.org/

[80] The Linux Documentation Project, http://www.tldp.org/

[81] http://www.linuxfromscratch.org/

[82] BYTEmark benchmark, BYTE Magazine, 1996,http://www.byte.com/bmark/bmark.htm

[83] J. Štěpán, K. Zvára: Pravděpodobnost a matematická statistika, Matfyzpress,1997, Praha

[84] M. Satyanarayanan: A study of file sizes and functional lifetimes, Proceedings of8th ACM Symposium on Operating Systems Principles, Asilomar, CA, Publishedas Operating Systems Review, 15(5):96–108, December 1981.

[85] Werner Vogels: File system usage in Windows NT 4.0, Department of ComputerScience, Cornell University, In Proceeding of the 17th ACM Symposium onOperating Systems Principles, published as Operating System Review 34, pp.93–109, December 1999, ISBN 1-58113-140-2

[86] Ousterhout, Da Costa, Harrison, Kunze, Kupfer, Thompson: A Trace–drivenAnalysis of the 4.2BSD UNIX file system, In Proceedings of the 10th Symposiumon Operating Systems Principles, ACM, New York, 1985, pp. 15–24

– 95 –

Dodatek A

Obsah CD-ROM

Součástí práce je i přiložené CD s protokoly měření, testovacími programy, všemivýsledky a dalšími grafy. Disk CD-ROM obsahuje následující adresáře:

� Thesis — zdrojové texty této práce ve formátu TEX a přeložený dokument veformátu Postscript.

� Results — výsledky měření a grafy.

� Creat — zdrojové texty vytvořených měřících nástrojů.

� Data — použitá vstupní data pro testovací programy.

� Download — stažené zdrojové kódy klientů testovaných souborových systémů apoužitých měřících nástrojů.

– 96 –

DIPLOMOV` PR`CE - cuni.cz

Documents

Transcript of DIPLOMOV` PR`CE - cuni.cz