Requirements of a Distributed File System
- Access Transparency: Programs written to operate local files are able to access remote ones without modification
- Location Transparency: Uniform name space, files maybe relocated without changing path-names
- Mobility Transparency: no change of administration tables or client programs when files are moved
- Performance Transparency: Clients continue to perform satisfactorily with load variations
- Scaling Transparency
Concurrent File Updates
Hardware and Operating System Heterogeneity
- at-least-once with idempotent operations
- Can be stateless to avoid state recovery after a crash
Consistency: Maybe some deviations from one-copy update semantics.
Security: clients need to be authenticated
Three main components are identified:
- flat file service and directory service: export their interfaces through RPC to be used by client modules
- client module: Programming interface to adapt file operations from different Operating Systems
Flat File Service:
- UFID (Unique File Identifier)
- Operating on the contents of files
- Idempotent operations
- Maps text names and UFIDs
- Client of Flat File Service
- Directory files stored in files
- Runs in each client computer
- Provides the standard file operation for the target OS
- Implements caches
- Access check when a filename is converted to UFID and returns a capability to the client
- User identity submitted with every client request
- Several file may be moved together between servers
- File cannot change to which group it belongs
Sun NFS File System
RPC interface to the NFS Server is open, any process can send request to a server.
In UNIX, NFS’ file handle derived from file’s i-node number adding two extra fields
- Filesystem Identifier: UNIX mountable filesystem as grouping unit, stored in the superblock.
- i-node generation number: In UNIX it is incremented each time the i-node is reused.
v-node related a remote file system to the local directory it is mounted.
In UNIX it is integrated with the kernel so:
- programs access files via system calls.
- a single cliente module used for all the user-level processes.
- encryption key passed to server retained in the kernel.
It share the same cache as local file systems
Several clients in different machines can access th same file so cache inconsistencies arise
Access Control and Authentication:
- Each request must include user credentials.
- DES Encryption and Kerberos added to the protocol
- A separate service deals with mounting using the mount protocol
- Takes directory pathname and credentials and returns file handle.
- hard-mounted: process suspended till operation has completed and keeps retrying if it is not available.
- soft-mounted: client returns a failure after a number of retries
Path Name Translation:
Performed iteratively by the client
each remote directory translated separately using lookup
Caching must be used
- Local NFS server
- Receives a lookup request and forwards it to servers, then create a symlink to avoid automounter in future requests
- No references to the symbolic link for a time leads to unmount it
- kernel implementations avoid the symlink
- NFS Servers use OS cache
- write-through caching, data received stored in cache and written before a reply is sent to the client
- commit caching, data is only written when a client issues a commit operation
- standard NFS Clients send commits when a file is closed
- Client module caches read, write, geattr, lookup and readdir
- Timestamp used to validate cached blocks
- Tc, last validation
- Tm, block last modification at the server
- range of time 30 – 60 secs
- Clients has no means to know whether a file is shared
- Validation must be done for every file
- First check (T – Tc) if false then Tm = Tmserver
- Recent updates not always visible to clients sharing the file
- read-ahead, delayed-write using bio-daemon.
NFS + Kerberos:
- Used only at mount time
- Server retains mounts at each client computer.
- No performance penalty comparing to local disks
- frequent use of getattr
- write-through at the server is poor
- Access Transparency: Delivered through client module.
- Location Transparency: Each client establishes file name space via mounted directories
- Mobility Transparency: When moving between servers clients must updates their tables too.
- Scalability: Adding disks or CPUs. Problems when some files are frequently accessed.
- File Replication: Not supported
- Hardware and OS Heterogeneity: Implemented for lots of OSs and hardware platforms
- Fault Tolerance: If the server crashes the clients continue at the same point they left when the server restarts
- Consistency: half achieved being close to one-copy semantics, ok for majority of applications. Not for coordination between computers
- Security: Must use Kerberos or other new mechanisms
- Efficiency: Used in heavy loads situations