File Systems 2

8/19/2019 File Systems 2

1/43

Distributed File Systems(II)


2/43

2

Outline

Last topics:

●Introduction

●Design of distributed file systems

●Implementation of distributed file systems

Now:

●Case studies: NFS !FS


3/43

3

Sun"s Networ# File System (NFS)

● NFS is a popular and widely used networ# file system● NFS was originally designed and implemented by

Sun $icrosystems for use on its %NI&'based

wor#stations● Oter manufacturers now support it as well for bot

%NI& and oter operating systems (including Linu

$S'DOS etc*)● NFS supports eterogeneous systems for eample

$S'DOS clients ma#ing use of %NI& ser+ers● It is not e+en re,uired tat all te macines use te

same ardware


4/43

4

Sun"s Networ# File System (NFS)

● -ree aspects of NFS are of interest:– arcitecture

– protocol– implementation


5/43

5

NFS !rcitecture●

-e basic idea beind NFS is to allow an arbitrary collectionof clients and ser+ers to sare a common file system– In most cases all te clients and ser+ers are on te same L!N

– NFS allows e+ery macine to be bot a client and a ser+er at

te same time

● Ser+er side:– .ac NFS ser+er eports one or more of its directories for

access by remote clients* /en a directory is made

a+ailable so are all of its sub'directories so te entire

directory tree is eported as a unit– -e list of directories a ser+er eports is maintained in te

0etc0eports file so tese directories can be eported

automatically wene+er te ser+er is booted


6/43

6

NFS !rcitecture (cont*)

●

Client (wor#station) side:– Clients access eported directories by mounting tem*

/en a client mounts a directory it becomes part of its

directory ierarcy

– ! dis#less wor#station can mount a remote file systemon its root directory resulting in a file system tat is

supported entirely on a remote ser+er

– -ose wor#stations tat a+e a local dis# can mount

remote directories anywere tey wis* -ere is nodifference between a remote file and a local file

– If two or more clients mount te same directory at te

same time tey can communicate by saring files in

teir common directories


7/43

7

NFS 1rotocols● ! protocol is a set of re,uests sent by clients to

ser+ers along wit te corresponding replies

sent by te ser+ers bac# to te clients– !s long as a ser+er recogni2es and can andle all te

re,uests in te protocols it need not #now anyting at

all about its clients

– Clients can treat ser+ers as 3blac# boes4 tat accepts

and process a specific set of re,uests5 ow tey do it is

teir own business

● NFS defines 6 protocols:– te protocol for mounting +olumes

– te protocol for directory and file access


8/43


9/43

9

$ount 1rotocol● NFS uses te mount protocol to access remote files

– $ount protocol establises a local name for remote files– %sers access remote files using local names5 OS ta#es care of te mapping


10/43

10

!utomounting

● Sun"s +ersion of %NI& also supports automounting● -is feature allows a set of remote directories to be

associated wit a local directory● None of tese remote directories are mounted (or teir

ser+ers e+en contacted) wen te client is booted● Instead te first time a remote file is opened te

operating system sends a message to eac of te

ser+ers* -e first one to reply wins and its directory is

mounted


11/43

11

NFS !utomounting

● !utomounting as two principal ad+antages o+er static mounting:– First in static mounting +ia te 0etc0rc file if one of te NFS ser+ers

appens to be down it is impossible to bring te client up '' at least not

witout some difficulty delay and ,uite a few error messages

– Second by allowing te client to try a set of ser+ers in parallel a degree of

fault tolerance can be acie+ed (because only one of tem need to be up)

and te performance can be impro+ed (by coosing te first one to reply ''presumably te least ea+ily loaded)

● On te oter and it is assumed tat all te file systems specified

as alternati+es for te automount are identical– Since NFS pro+ides no support for file or directory replication it is up to te

user to arrange for all te file systems to be te same● -us automounting is most often used for read'only file systems

containing system binaries and oter files tat rarely cange


12/43

12

NFS 1rotocols: Directory and File !ccess● Clients can send messages to ser+ers to manipulate directories

and to read and write files* -ey can also access file attributessuc as file mode si2e and time of last modification* $ost %NI&

system calls are supported by NFS*

● In NFS eac message is self'contained– -e ad+antage of tis sceme is tat te ser+er does not a+e to remember

anyting about open connections in between calls to it* -us if a ser+ercrases and ten reco+ers no information about open files is lost because

tere is none*

● ! ser+er li#e tis tat does not maintain state information

about open files is said to be stateless server ● In contrast in %NI& System 7 te 8emote File System (8FS)

re,uires a file to be opened before it can be read or written*– -e ser+er ten ma#es a table entry #eeping trac# of te file is open and

were te reader currently is so eac re,uest need not carry an offset*– -e disad+antage of tis sceme is tat if a ser+er crases and ten

,uic#ly reboots all open connections are lost and client programs fails*


13/43

13

File System Operations (9)

!n incomplete list of file system operations supported by NFS


14/43

14

File System Operations (6)

!n incomplete list of file system operations supported by NFS


15/43

15

●

-e NFS sceme ma#es it difficult to acie+e te eact%NI& file semantics*

● In %NI& a file can be opened and loc#ed so tat oter

processes cannot access it*●

/en te file is closed te loc#s are released*● In a stateless ser+er suc as NFS loc#s cannot be

associated wit open files because te ser+er does

not #now wic files are open* NFS terefore needs a

separate additional mecanism to andle loc#ing*

NFS 1rotocols: Directory and File !ccess


16/43

16

● NFS uses te %NI& protection mecanism wit rw bits for

te owner group and oters*● Originally eac re,uest message simply contained te user

and group ids of te caller wic te NFS ser+er used to

+alidate te access*

–

In effect it trusted te clients not to ceat*● Currently public #ey cryptograpy can be used to establis

a secure #ey for +alidating te client and ser+er on eac

re,uest and reply*– /en tis option is enabled a malicious client cannot impersonate

anoter client because it does not #now tat client"s secret #ey*

● !s an aside cryptograpy is used only to autenticate te

parties* -e data temsel+es are ne+er encrypted*

NFS 1rotocols: Directory and File !ccess


17/43

17

Networ# Information Ser+ice (NIS)● !ll te #eys used for te autentication as well as oter information are

maintained by te NIS (Networ# Information Ser+ice)● -e NIS was formerly #nown as te yellow pages● Its function is to store (#ey +alue) pairs

– /en a #ey is pro+ided it returns te corresponding +alue*

– Not only does it andle encryption #eys but it also stores te mapping of

user names to (encrypted) passwords as well as te mapping of macinenames to networ# addresses and oter items*

● -e networ# information ser+ers are replicated using a master0sla+e

arrangement

– -o read teir data a process can use eiter te master or any of te copies

in te sla+es*

– owe+er all canges must be made only to te master wic ten

propagates tem to te sla+es*

– -ere is a sort inter+al after an update in wic te NIS ser+er is

inconsistent*


18/43

18

Implementation: NFS Layer Structure


19/43

19

NFS Implementation● It consists of tree layers:

– System call layer :

-is andles calls li#e O1.N 8.!D and CLOS.*

– Virtual file system (VFS):

-e tas# of te 7FS layer is to maintain a table wit one entry for

eac open file analogous to te table of I'nodes for open files in%NI&* 7FS layers as an entry called a +'node (+irtual i'node) for

e+ery open file telling weter te file is local or remote*

– NFS client code:

%sed to create an r'node (remote i'node) in its internal tables to old

te file andles* -e +'node points to te r'node* .ac +'node in te7FS layer will ultimately contain eiter a pointer to an r'node in te

NFS client code or a pointer to an i'node in te local operating

system* -us from te +'node it is possible to see if a file or directory

is local or remote and if it is remote to find its file andle*


20/43

20

NFS Implementation (cont*)

● %se client cacing to impro+e te performance:– -ransfer between client and ser+er are done in large

cun#s normally ;


21/43

21

NFS Implementation (cont*)● Client cacing impro+es performance

– 1roblem: 6 clients cacing te same file bloc# and tat one of temmodifies it* /en te oter one reads te bloc# it gets te old +alue*

– Solutions:● Solution 9:

– !ssociate wit eac cace bloc# a timer wen te timer epires te

entry is discarded* Normally te timer is > sec* for data bloc#s and

>? sec* for directory bloc#*

● Solution 6:– /ene+er a caced file is open a message is sent to te ser+er to

find out wen te file was last modified*

– If te last modification occurred after te local copy was caced te

caced copy is discarded and te new copy fetced from te ser+er*

– Finally once e+ery >? sec* a cace timer epires and all te dirty

bloc#s in te cace are sent to te ser+er*


22/43


23/43

23

NFS Implementation (cont*)

● Lessons learned:– /or#stations a+e cycles to burn so do it on te

client'side not te ser+er'side

– Cace wene+er possible

– .ploit te usage properties

– $inimi2e systemwide #nowledge and cange

– -rust te fewest possible entities

–

@atc wor# were possible


24/43

24

-e !ndrew File System (!FS)

● ! different approac to remote file access

● $eant to ser+ice a large organi2ation

– Suc as a uni+ersity campus● Scaling is a ma=or goal


25/43

25

@asic !FS $odel

● Files are stored permanently at file ser+er

macines

● %sers wor# from wor#station macines– /it teir own pri+ate namespace

● !ndrew pro+ides mecanisms to cace user"s

files from sared namespace


26/43

26

@asic !FS $odel (cont*)

● %ser model of !FS use:– Sit down at any !FS wor#station anywere

– Log in and autenticate wo I am

– !ccess all files witout regard to wic wor#station I"musing

● -e local namespace:

–

.ac wor#station stores a few files– $ostly system programs and configuration files

– /or#stations are treated as generic intercangeable

entities


27/43

27

7irtue and 7ice

● 7ice is te system run by te file ser+ers– Distributed system

●

7irtue is te protocol client wor#stationsuse to communicate to 7ice


28/43

28

O+erall !rcitecture

● System is +iewed as a /!N composed

of L!Ns

●

.ac L!N as a 7ice cluster ser+er – /ic stores local files

● @ut 7ice ma#es all files a+ailable to all

clients


29/43

29

!FS !rcitecture Diagram

L!N

/!N

L!N

L!N


30/43

30

Cacing te %ser Files

● Aoal is to offload wor# from ser+ers to clients

● /en must ser+ers do wor#B– -o answer re,uests

– -o mo+e data

● /ole files caced at clients* /yB 8easons:– $inimi2es communications wit ser+er

–

$ost files used in entirety anyway– .asier cace management problem

– 8e,uires substantial free dis# space on wor#stations

● Doesn"t address uge file problems


31/43

31

-e Sared Namespace

● !n !ndrew installation as global sared

namespace

● !ll client"s files are +iewed in te namespacewit te same names

● ig degree of name and location transparency


32/43

32

ow do ser+ers pro+ide te

namespaceB● Files are organi2ed into +olumes

● 7olumes are grafted togeter into o+erall

namespace● .ac file as globally uni,ue ID

● 7olumes are stored at indi+idual ser+ers

– @ut a +olume can be mo+ed from ser+er to ser+er


33/43

33

Finding a File

● !t ig le+el files a+e names

● Directory translates name to uni,ue ID

● If client #nows were te +olume is it simplysends uni,ue ID to appropriate ser+er


34/43

34

Finding a 7olume

● /at if you enter a new +olumeB– ow do you find wic ser+er stores te +olumeB

●

7olume'location database stored on eac ser+er ● Once information on +olume is #nown client

caces it


35/43

35

$a#ing a 7olume

● /en a +olume mo+es from ser+er to ser+er

update database–

ea+yweigt distributed operation● /at about clients wit caced informationB

● Old ser+er maintains forwarding info– !lso eases ser+er update


36/43

36

andling Caced Files : 7enus

● Files fetced transparently wen needed● File system traps opens

– Sends tem to local Venus process

● -e 7enus Daemon:– 8esponsible for andling single client cace

– Caces files on open

– /rites modified +ersions bac# on close


37/43

37

Consistency for !FS

● If my wor#station as a locally caced copy

of a file wat if someone else canges itB

●

Callbac#s used to in+alidate my copy● 8e,uires ser+ers to #eep info on wo caces

files


38/43

38

/rite Consistency in !FS

● /at if I write to my caced copy of a fileB

● Need to get write permission from ser+er – /ic in+alidates anyone else"s callbac#

● 1ermission obtained on open for write● Need to obtain new data at tis point

● Initially written only to local copy

● On close 7enus sends update to ser+er ● Ser+er will in+alidate callbac#s for oter copies

● .tra mecanism to andle failures


39/43

39

Storage of !ndrew Files

● Stored in %NI& file systems

● Client cace is a directory on local macine–

Low'le+el names do not matc !ndrew names


40/43

40

7enus Cace $anagement

● 7enus #eeps two caces– Status

–

Data● Status cace #ept in +irtual memory

– For fast attribute loo#up

● Data cace #ept on dis#


41/43

41

7enus 1rocess !rcitecture

● 7enus is a single user process

● @ut multitreaded

●

%ses 81C to tal# to ser+er – 81C is built on low le+el datagram ser+ice


42/43

42

!FS Security

● Only ser+er07ice are trusted ere– Client macines migt be corrupted

● No client programs run on 7ice macines● Clients must autenticate temsel+es to ser+ers

● .ncryption used to protect transmissions

!FS Fil 1 t ti


43/43

43

!FS File 1rotection

●

!FS supports access control lists– .ac file as list of users wo can access it

– !nd permitted modes of access

● $aintained by 7ice

● %sed to mimic %NI& access control

!FS 8ead'Only 8eplication● For +olumes containing files tat are used fre,uently

but not canged often (e*g* eecutables) !FS allows

multiple ser+ers to store read'only copies

File Systems 2

Documents

Transcript of File Systems 2