Question 4 of 6: Distributed File Systems

Question 4: Distributed File Systems

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Five key benefits of a distributed file system. 1. Location transparency — files are named and accessed the same way regardless of which server physically stores them. 2. Access transparency — local and remote files are opened, read and written through the same interface, so existing single-machine applications need little or no change. 3. Scalability and shared access — many users across many client machines can share the same data without each needing a local copy, and capacity can grow by adding servers. 4. Fault tolerance and availability — replication across multiple servers means the loss of one machine need not make the data unavailable. 5. Reduced administrative and storage overhead — data, backups and access control are managed centrally rather than duplicated per workstation, and client-side caching reduces both server load and the local storage every client needs.

(b) NFS vs. Hadoop (HDFS) — performance, fault-tolerance, replication. Performance. NFS is optimized for general-purpose, low-latency, POSIX-style file access — small reads/writes, random access, many small files — typical of everyday interactive use over a LAN. Hadoop's HDFS is optimized for very large files split into large fixed-size blocks (traditionally 128 MB+) accessed in big sequential scans for batch analytics; a single small read on HDFS carries far more overhead than on NFS, but HDFS's aggregate throughput across a cluster for large sequential workloads vastly exceeds a single NFS server. Fault tolerance. Classic NFS has no built-in fault tolerance of its own — a server (or its underlying disk) failing takes its exported filesystem down unless the deployment adds external HA (RAID, failover clustering). HDFS is fault-tolerant by design: the NameNode continuously tracks each block's replica locations and automatically re-replicates any block whose replica count falls below the configured target when a DataNode is lost. Replication. NFS provides no native data replication (any redundancy is bolted on outside the protocol, e.g. via RAID or a separate backup system). HDFS replicates every block, by default three-way, across different DataNodes (and ideally different racks) automatically as part of normal write operation, and uses that replication both for fault tolerance and for improving read parallelism/data locality for MapReduce-style jobs.

(c) Stateless server. A stateless server keeps no per-client session information between requests — each request must be entirely self-describing (e.g. in classic NFS, every RPC call carries the file handle, the byte offset and the operation to perform, rather than the server remembering "client X currently has file Y open at offset Z"). This makes crash recovery trivial: if the server crashes and restarts, it has no session state to lose or reconstruct, and clients simply retry their next self-contained request once the server is back — at the cost of larger per-request messages and losing any optimization that would come from the server remembering per-client context (e.g. read-ahead based on a known sequential access pattern, or holding locks across calls without extra protocol).

(d) Caching in remote file access. Caching's core advantage is reducing both perceived latency and network/server load: a file (or block) fetched once and kept locally can satisfy every subsequent access without another round trip, which matters enormously for repeatedly-read files and for read-heavy workloads generally. Client-side caching (in the requesting host's own memory or local disk) gives the lowest possible latency on a hit (no network hop at all) and directly offloads the server, but each client's cache is invisible to every other client, so keeping many independent caches consistent when a file is modified requires an explicit invalidation/callback mechanism (as AFS does), and every client pays its own local storage cost. Network/proxy caching (a shared cache at a proxy server or gateway between many clients and the origin server) benefits every client behind it from a single fetch, giving a much higher aggregate hit rate for content popular across an organization and reducing WAN bandwidth to the origin, but it adds a shared point of failure/bottleneck, still needs a coherency mechanism when the origin data changes, and does nothing for content that is popular with only one particular client rather than the group as a whole.