Distributed file storage makes familiar file operations survive hardware and network failures by spreading responsibility across multiple machines. The user-visible result shows up as durability when data stays intact after failures, availability when reads and writes still succeed, consistency when different clients see the same contents and names, and latency when operations complete quickly enough to be usable. To ground those terms, compare how a single disk and a small cluster behave when something breaks. The Core Model Durability and availability often pull in different directions. A system can keep data safe by waiting for multiple replicas to acknowledge a write, but that same waiting raises latency and can reduce availability during failures. Consistency also competes with availability because a partition can force a choice between returning a stale answer quickly or refusing to answer until the system is sure. Data and metadata split the work A distributed file system separates file contents from the information that locates and names them. Data is stored as blocks or chunks on storage nodes, while metadata records mappings such as file name to inode, inode to block list, permissions, timestamps, and directory structure. Trace a few common operations through a client, a metadata service, and storage nodes. Most reads and writes touch metadata first. open() resolves a path and checks permissions, read() needs the block list and locations, and rename() updates directory entries and often requires atomicity across multiple metadata records. Because many clients repeatedly hit the same metadata paths, metadata becomes a bottleneck before raw storage bandwidth does. Bottleneck signal When storage nodes look idle but client operations stall, the metadata service is often saturated or contended.