Distributed File Systems

1
Distributed File Systems

• Ref Tanenbaum, chpt 10

2
Overview

• Seven main issues (distributed systems in
  general)
• Communication
• Processes
• Naming
• Synchronization
• Caching and Replication
• Fault Tolerance
• Security
• Here, discuss in context of Sun Network File
  System (NFS) as an important example

3
Sun NFS Overview

• Originally developed for Sun workstations, now
  realized on many other systems
• Collection of file servers, each providing a
  standardized view of its local file system
• File servers may run on different architectures
  with different local OS, local file system
  implementation
• Clients see a common interface to the file system
• NFS is really a set of standardized protocols
  defining a common model which can be implemented
  by different OSs
• NFS Model
• Remote file service - file system implemented on
  a remote server
• Remote access model - set of file operations
  defining the service main requirement is servers
  must implement this model

4
NFS Architecture

• The remote access model
• The upload/download model
• Nominally, NFS uses the remote access model,
  though when caching is added, it starts to look
  more like the upload/download model

5
NFS Architecture

• Basic NFS architecture for UNIX systems
• RPC used to achieve platform independence
• Client Virtual File System replaces local file
  system interface
• Server Incoming requests mapped to VFS operations

6
NFS File Operations

• VFS model similar to Unix file system model
• File uninterpreted sequence of bytes
• Hierarchical file system nodes represent
  directories and files
• Files accessed by a file handle (gotten from name
  service)

7
Issue 1 Communication

• Goal Independence from OS, network architecture,
  transport protocol
• Communications built over Open Network Computing
  (ONC) RPC

• Reading data from a file in NFS version 3
• Reading data using a compound procedure in
  version 4
• Obvious performance advantage, especially over
  WAN
• No transactional semantics
• No measures to avoid conflicts in concurrent
  operations
• If one operation fails, remaining operations
  aborted

8
Issue 2 Processes

• Traditional client / server approach
• Clients request file operations on file servers
• Versions 2, 3 stateless
• Servers need not keep any client state
  information from one file operation to the next
• Simple, e.g., if client crashes
• In practice, servers maintained a little client
  information (file locking, authentication
  protocols may be difficult to implement w/o
  state)
• Version 4 is stateful (e.g., open operation)
• One reason is to support WAN (reduce
  communication by using caching)
• Client can cache files consistency protocol
  needed, requiring state information at server to
  track what files are used by clients

9
Issue 3 Naming

• Goal Transparent access to remote file system
• Achieved by client mounting a directory from a
  remote file system onto the local machine

• The same file can have different names for
  different clients (no shared name space) makes
  sharing harder
• Can use convention so remote file systems are
  mounted at same place in local name space on
  different systems

10
Other Naming Issues

• File handles
• Reference to a file independent of the file name
• Defined by file system hosting file when file is
  created
• Unique among file systems exported by that server
• When to mount file system Automounting
• Would like to automatically mount directory as
  needed, e.g., when user logs in, mount the users
  home directory
• Should other files be mounted then (e.g., other
  users whos files are accessible)? Files will be
  guaranteed to be mounted, but this could be
  expensive if many users
• On-demand mounting - mount directory dynamically
  when it is first referenced
• Automounter program at client responsible for
  mounting directory
• Performance issue overhead to check with
  automounter on file operations

11
File Attributes

• V.3 fixed set of attributes all implementations
  expected to support difficult for some
  implementations (e.g., Windows)
• V.4 Mandatory, recommended, and other attributes

12
Issue 4 SynchronizationSemantics of File Sharing

• On a single processor, when a read follows a
  write, the value returned by the read is the
  value just written.
• In a distributed system with caching, obsolete
  values may be returned.
• Could propagate changes to server immediately -
  inefficient

13
Semantics of File Sharing

• Alternate approach relax semantics
• Four ways of dealing with the shared files in a
  distributed system

• Session semantics widely used adopted in NFS
• Concurrent writes final contents reflects that
  of last client to close file

14
File Locking in NFS

• Four NFS v. 4 operations related to file locking
• Distinguishes between read and write locks

15
Issue 5 Caching and Replication

• Version 3
• Caching not included in protocol, leading to
  different implementations, different levels of
  consistency (cached data may be stale for
  seconds, perhaps 30 seconds, depending on
  implementation)
• Version 4
• Open caches data, close writes to server if
  modified (session semantics)
• Data may remain in cache, but must be validated
  the next time a client on same processor opens
  file (check modification timestamp)
• Open delegation Server can delegate some
  checking (e.g., to see if open succeeds) to
  client, allowing requests by other clients on
  same machine to be done locally server can
  recall delegation (server must remember who it
  delegated to)

16
Issue 6 Fault Tolerance

• V.3 Stateless, so recovery relatively
  straightforward
• V.4 statefulness makes failure a more important
  issue two problems
• RPC failures
• Locking (note v.3 still has to deal with locking)

17
Issue 6 Fault ToleranceRPC Failures

• Client retransmits request if timeout for RPC
  expires
• If RPC reply is lost, may generate duplicate
  requests undesirable for non-idempotent
  operations
• Three situations for handling retransmissions.
• The request is still in progress ignore
  duplicate request
• The reply has just been returned when duplicate
  request received server ignores duplicate
• The reply has been some time ago, but was lost
  retransmit cached result of the file operation

18
Fault Tolerance Locking

• Main issue how to handle client/server failures
  when a file is locked
• Client Failure
• Lock duration limited to time of lease
  automatically released once lease expires
• Client must explicitly renew lease to maintain
  lock problem if renewal is delayed
• Server failure
• Server lost state of which locks were held
• Upon recovery, server enters grace period where
  no new lock requests are processed, but clients
  can request to re-claim locks so server can
  (hopefully!) recover state

19
Issue 7 Security

• Secure RPC
• Three authentication mechanisms provided
• Access rights checked by server
• Relatively rich set of access rights

20
Summary

• NFS an example of a distributed client/server
  system
• Main issues
• Communication
• Processes
• Naming
• Synchronization
• Caching and Replication
• Fault Tolerance
• Security