Project Group High- performance Flexible File System

Transcription

1 Project Group High- performance Flexible File System Lecture 3: Network File Systems André Brinkmann

2 Example: SUN NFS NFS (Network File System) is an open protocol to exchange files Developed by Sun Microsystems and published as NFS Version 2 (RFC 1094) in 1989 Simple and open interfaces Supports the following properwes of distributed file systems transparency heterogeneity (limited for Windows) efficiency fault tolerance The following properwes are only parwally supported concurrency replicawon consistency security

3 NFS v3 Architecture

4 Where should NFS be implemented? NFS has not to be implemented in OS kernel space NFS can also be implemented as library or user space process Examples: Windows and Mac OS implementawons, PocketPC Advantages of a kernel space implementawon under UNIX Programs are not forced to be recompiled for different NFS implementawons to adapt the library Systems calls for remote files can be routed directly to the NFS module Cache for currently used files of the OS Kernel level server can directly access inodes and data blocks Also possible for privileged user space process Security of the encrypwon

5 NFS v3 operawons read(&, offset, count) è a1r, data write(&, offset, count, data) è a1r create(dir&, name, a1r) è new&, a1r remove(dir&, name) status geta1r(&) è a1r seta1r(&, a1r) è a1r lookup(dir&, name) è &, a1r rename(dir&, name, todir&, toname) link(newdir&, newname, dir&, name) readdir(dir&, cookie, count) è entries symlink(newdir&, newname, string) è status readlink(&) è string mkdir(dir&, name, a1r) è new&, a1r rmdir(dir&, name) è status sta;s(&) è fsstats Model flat file service: fh = file handle Read(FileId, i, n) -> Data Write(FileId, i, Data) Create() -> FileId Delete(FileId) GetAttributes(FileId) -> Attr SetAttributes(FileId, Attr) Filesystem Identifier inode-number inode-generation Model directory services: Lookup(Dir, Name) è FileId AddName(Dir, Name, File) UnName(Dir, Name) GetNames(Dir, Pattern) è NameSeq

6 NFS v3 authorizawon and authenwcawon AuthenWcaWon is done on client Joint authenwcawon files necessary NFS Version 3 is stateless, so that the idenwty and the access permissions are checked on each access to the server Local file systems check the permission only during the open call Each access of a client is enhanced by the user and group informawon InformaWon is inserted in RPC call Server can be adacked if user and group informawon is not secured by an encrypwon scheme Kerberos can be integrated directly into NFS

7 Mount service Mount- OperaWon: mount(remotehost, remotedirectory, localdirectory) Server holds table with clients that have mounted a file system of the server Each client maintains a table with all mounted file systems <IP address, port number, file handle>

8 Local and remote filesystems with NFS clients The directory students on the client is equal to the people directory on server 1 The directory staff on the client is equal to the users directory on server 2

9 Automounter NFS Client tries to find empty mount points and delegates them to the automounter Automounter has a table of mount points and mulwple candidates Automounter sends requests to candidates and mounts the file system from the server that answers first mount tables are kept smaller Simple form of replicawon of read- only file systems Example (simplified): Each user has the /home directory Automounter installs the directory during the boowng of the client If user accesses the directory mustermann, it is requested by the automounter on different NFS servers If different server have idenwcal /usr/lib, each server has a chance of being accessed

10 NFS v3 opwmizawon: Server Caching Similar to UNIX file caching of local files Pages (Blocks) of the hard disk are kept in memory unwl replaced by newer pages OpWmizaWons for read- ahead and delayed- write NFS v3 provides two strategies to write files write- through: Dirty pages are immediately wriden to a storage system when they arrive at the server. When the write()- RPC returns, the NFS client has the guarantee that data is on disk delayed commit: Pages are kept in a cache unwl a commit()- call (Default for NFS v3). A commit() is done by a client, e.g. when a file is closed. AddiWonal reply cache: Logs previous requests When a client sends a request mulwple Wmes, the cache already stores correct response (solves problems with non- idempotent requests as rm)

11 NFS v3 opwmizawon: Client Caching Caching not explicit in protocol Server caching does not reduce network traffic between clients and server Further opwmizawon necessary to reduce traffic in large networks NFS client stores results for read, write, getadr, lookup and readdir operawons SynchronizaWon of file contents is not ensured if two or more clients access same file ValidaWon based on Wmestamps Reduces inconsistencies, but does not eliminate them ValidaWon properwes for cache entries of the client: (T - Tc < t) (Tm client = Tm server ) t can be configured (per file) and is typically set to 3 seconds for files and 30 seconds for directories WriWng of distributed applicawons with NFS is swll difficult t: Refresh period Tc: Time of last validation Tm: Time of last update T: Current time

12 NFS v3 Summary I NFS is an example for a simple, robust, and distributed file system EvaluaWon of properwes Access transparency: very good; API can use same UNIX syntax for local and remote accesses locawon transparency: Not ensured; Names of file systems are specified during mount operawon. Good system configurawon can achieve transparency Concurrency: Limited; If mulwple clients write to a single file, consistency is not ensured ReplicaWon: Limited to read- only file systems Fault tolerance: Limited; Service is down when server crashes. Ajer Restart the server is restored using stateless protocol

13 NFS v3 Summary II Data mobility: barely possible; Transparent file moves are not possible. Complete file systems can be moved, but this needs a change in the client configurawon Performance:? Scalability:?

14 NFS v3 è NFS v4 NFS v4 standardized under RFC 3530 UNIX user and group numbers are replaced by strings, e.g. IntroducWon of temporary file handles that exists only for a limited Wme Mount and lock protocol are parts of the protocol itself and run on a specified port. The usage of firewalls with NFS connecwons is made simpler MulWple requests can be combined into a single call. They are executed by the server and only a single response is sent back. Protocol can be made more efficient on Wide Area Networks EncrypWon is part of the spec. SecureRPC has been possible before, but it was only seldom used, because it was not always available The Lookup call is replaced by open. Write/Read posiwon is maintained on the server If many clients only read a file, this file can be given to all clients. If a client wants to write a file, an exclusive lock can be granted Slide based on Wikipedia.de