A distributed file system (DFS) allows users to access files and directories located on remote computers as if they were local. It provides a transparent, integrated view of files spread across multiple machines in a network.

11.3.1. Naming and Transparency

Naming: How files and directories are identified and located in a DFS.
- Location-Independent Naming: The name of a file does not reveal its physical location (server, disk). This allows files to be moved between servers without changing their names, promoting flexibility and fault tolerance. (e.g., /serverA/dir/file.txt vs. /users/john/file.txt where /users/john is mapped to a remote server).
- Global Namespace: A single, unified hierarchical namespace that encompasses all files and directories across all participating servers in the DFS. This makes it easier for users to locate files without needing to know which server stores them. (e.g., /usr/local/bin could be on one server, while /home is on another, but both appear as part of the same root hierarchy).
- Mounting: Often, remote file systems are "mounted" into a local directory hierarchy, making them appear as a subtree of the local file system.

Transparency: The degree to which the distributed nature of the file system is hidden from the user and applications. The goal is to make the DFS behave as much like a local file system as possible.
- Access Transparency: Users and applications access files in the same way, whether they are local or remote. The file operations (open, read, write) are identical regardless of file location.
- Location Transparency: The location of the file is hidden from the user. The user does not need to know which server hosts the file. This is directly related to location-independent naming.
- Migration Transparency: Files can be moved between servers without affecting their names or the way they are accessed by clients.
- Replication Transparency: If a file is replicated on multiple servers for availability or performance, the user is unaware of the copies. The DFS automatically manages consistency among replicas.
- Concurrency Transparency: Multiple users accessing the same file concurrently do not need to be aware of each other's operations. The DFS handles concurrent access and consistency.
- Failure Transparency: The DFS attempts to hide failures of servers or network links from the user, possibly by transparently switching to a replica.
- Scaling Transparency: The system can scale up or down (add/remove servers) without disrupting user operations or requiring changes to application code.

11.3.2. Remote File Access

• Client-Server Model: Most DFS implementations follow a client-server model. Clients issue file access requests, and file servers respond.
• Communication Protocols: DFSs rely on specific network protocols for communication between clients and servers. Examples include:
• NFS (Network File System): A widely used open standard, initially developed by Sun Microsystems. Clients send RPC requests to NFS servers.
• SMB/CIFS (Server Message Block/Common Internet File System): Developed by IBM and popularized by Microsoft (Windows file sharing).
• Caching: To improve performance and reduce network traffic, DFS clients often implement caching.
• Client-Side Caching: Clients store copies of recently accessed file blocks or directory entries in their local memory or disk.
• Read-Ahead/Write-Behind: Strategies to proactively fetch data or buffer writes to disk.
• Consistency Issues: Caching introduces cache consistency problems. If a client caches a file block and another client modifies the original file on the server, the cached copy becomes stale.
• Cache Consistency Protocols:
  • Write-Through: Every write from the client is immediately written to the server, ensuring consistency but higher latency.
  • Write-Back (Delayed Write): Writes are buffered locally on the client and written back to the server periodically. Faster for the client but can lead to data loss if the client crashes before writes are committed.
  • Leasing: The server grants a "lease" to a client for a cached block. The client can use the cached block for the duration of the lease. If the server needs to revoke the lease (e.g., another client requests a write), it can notify the client.
  • Server-Initiated Cache Invalidation: When a server detects a change to a file, it actively sends invalidation messages to all clients known to have cached that file.
• Stateful vs. Stateless Servers:
• Stateless Server: The server does not maintain any information about the client's open files or previous requests. Each request from the client is self-contained.
  • Advantages: Simpler recovery from server crashes (server can just restart), easier to scale (any server can handle any request), no need to manage client state.
  • Disadvantages: Might require clients to re-transmit more information with each request, potentially less efficient for sequential access.
  • Example: Early versions of NFS.
• Stateful Server: The server maintains information about the client's open files, file pointers, and other session-specific data.
  • Advantages: Can optimize performance by prefetching data or improving cache consistency with less client overhead, supports features like file locking more easily.
  • Disadvantages: More complex to implement server crash recovery (server needs to rebuild state), harder to scale, might consume more server resources to manage client state.
  • Example: SMB/CIFS, later versions of NFS (with NLM for locking).