Network File Systems

In 1984, Sun Microsystems introduced a technology that would fundamentally reshape how we think about file storage and access: the Network File System (NFS). The premise was revolutionary yet elegantly simple—what if accessing a file on a remote machine could be indistinguishable from accessing a file on your local disk?

This concept, known as location transparency, became the foundation for modern distributed computing. Before NFS, sharing files between computers required explicit copy operations, FTP transfers, or cumbersome remote mounting procedures that demanded users to understand network topology. NFS changed this paradigm by allowing remote file systems to be mounted just like local disks, with applications completely unaware that the data resided miles—or continents—away.

Today, NFS and its conceptual descendants underpin everything from enterprise data centers to cloud storage services. Understanding NFS is essential for any systems engineer because it illuminates the fundamental challenges of distributed systems: consistency, reliability, performance, and the delicate balance between simplicity and correctness.

To understand NFS, we must first understand the problem it was designed to solve. In the early 1980s, computing environments faced a fundamental challenge: data fragmentation across isolated machines.

The Pre-NFS World

Consider a typical computing environment before network file systems:

• Each workstation had its own local disk storage
• Users had to log into specific machines to access their files
• Sharing data required explicit file transfers via FTP, rcp, or physical media
• Backup and administration required managing each machine individually
• Software installation had to be repeated on every workstation
• Disk space was expensive and often underutilized (one machine full, another nearly empty)

This model created numerous operational nightmares:

Sun's Vision: Diskless Workstations

Sun Microsystems, founded in 1982, had a radical vision for solving these problems: diskless workstations. Their idea was to build powerful graphical workstations without local storage. All data and even operating system files would be served over the network from centralized servers.

This approach offered compelling advantages:

• Centralized Administration — Manage storage, backups, and software from a single location
• Resource Pooling — Aggregate storage capacity could be allocated dynamically
• User Mobility — Log in from any workstation and see your complete environment
• Cost Reduction — Workstations without disks were cheaper; central storage could use higher-quality hardware
• Reliability — Professional storage servers could have redundant disks, professional backups, etc.

But realizing this vision required a new kind of file system—one that could make network resources appear local.

The NFS designers at Sun faced a challenging design space. They needed a system that was simple enough to implement reliably, performant enough for interactive use, and robust enough to survive network and server failures. The resulting design philosophy can be understood through several key principles:

The Stateless Server Decision

Perhaps the most consequential design decision was making the NFS server stateless. Unlike many network protocols where the server maintains information about each client's session, an NFS server treats each request as independent. The server retains no memory of past requests or client state.

This was a controversial choice. A stateful design would offer significant performance benefits (the server could cache client information, track open files, send change notifications). But the NFS designers prioritized crash recovery above all else:

Stateful Server Crash Scenario:

1. Client opens file, server records 'Client A has file X open'
2. Server crashes and reboots
3. Server has lost all session state
4. Client A's file handle is now invalid
5. Client must detect failure, reconnect, and reopen files
6. Complex recovery logic on both sides

Stateless Server Crash Scenario:

1. Client opens file (server records nothing)
2. Server crashes and reboots
3. Client's request times out
4. Client automatically retries the same request
5. Server handles request as if nothing happened
6. Operation succeeds transparently

The stateless approach dramatically simplified crash recovery—clients simply retry until the server comes back up. This idempotent request model became a fundamental characteristic of NFS.

The Trade-off: Consistency vs. Simplicity

The stateless approach came with trade-offs that persist in NFS to this day:

Advantages of Stateless Design:

• Server can crash and reboot without complex recovery protocols
• No limit on the number of clients (no per-client state to maintain)
• Server implementation is simpler and less bug-prone
• Load balancing is straightforward (any server can handle any request)

Disadvantages of Stateless Design:

• No server-side cache invalidation (clients don't know when files change)
• Locking requires a separate, stateful protocol
• Some operations cannot be made idempotent (e.g., creating a unique filename)
• Clients must poll to detect changes

These trade-offs would shape NFS's evolution across its various versions, with later designs adding limited statefulness to address the most painful limitations.

Understanding how NFS provides file access requires understanding its core abstractions: file handles, mount points, and the remote procedure call mechanism that ties everything together.

File Handles: The Universal Identifier

In local file systems, files are typically identified by inode numbers—simple integers that index into a table on a specific disk. But in a network environment, we need a way to uniquely identify files across machines. NFS accomplishes this with file handles.

A file handle is an opaque byte sequence (typically 32-64 bytes) that uniquely identifies a file on a particular server. The handle encodes enough information for the server to locate the file, but its internal structure is intentionally hidden from clients.

A typical file handle might contain:

• File system identifier — Which file system on the server
• Inode number — The file's identity within that file system
• Generation number — A version counter that changes when inodes are reused

The generation number is crucial for correctness. Without it, a sequence like:

1. Client gets handle for file with inode 42
2. File is deleted, inode 42 is freed
3. New file is created, assigned inode 42
4. Client uses old handle, accesses wrong file!

The generation number ensures stale handles are detected: the new file at inode 42 has a different generation number, so the old handle won't match.

Mount Points: Connecting Remote File Systems

NFS relies on the standard UNIX mount mechanism to integrate remote file systems into the local directory tree. When a client mounts an NFS export, it creates a mount point where the remote file system appears.

For example:

mount server.example.com:/export/home /home

This command mounts the remote path /export/home from server.example.com at the local path /home. After this, any access to /home/alice/document.txt transparently becomes an NFS operation to access /export/home/alice/document.txt on the server.

The mount process involves:

1. Contact the mount daemon — The client connects to the server's mount service
2. Authentication — The server verifies the client is allowed to access the export
3. File handle exchange — The server provides the root file handle for the exported path
4. Kernel configuration — The client kernel records the mount point and associated file handle

Once mounted, the NFS file system is integrated into the Virtual File System (VFS) layer. All standard file operations go through VFS, which routes them to the appropriate handler—local disk or NFS client.

NFS is built on top of Remote Procedure Call (RPC), a protocol that allows programs to execute procedures on remote machines as if they were local function calls. Understanding RPC is essential to understanding how NFS actually works.

The RPC Abstraction

RPC provides a powerful abstraction: instead of thinking about network sockets, message formats, and serialization, a programmer can simply 'call a function' that happens to execute on a remote machine. The RPC infrastructure handles all the networking details.

From the programmer's perspective:

// This looks like a local function call
result = nfs_read(file_handle, offset, count);

// But behind the scenes:
// 1. Arguments are serialized into a network message
// 2. Message is sent to the server
// 3. Server deserializes and executes the actual function
// 4. Result is serialized and sent back
// 5. Client deserializes result and returns it

Sun RPC (ONC RPC)

NFS uses Sun RPC, also known as ONC (Open Network Computing) RPC. This protocol defines:

• Program Number — A unique identifier for each RPC service (NFS is program 100003)
• Version Number — Allows protocol evolution while maintaining compatibility
• Procedure Number — Identifies specific operations within a program
• XDR (External Data Representation) — A standard format for encoding data that handles byte ordering and type conversion across different architectures

When a client wants to perform an NFS operation, it constructs an RPC request containing:

• The program number (100003 for NFS)
• The version number (2, 3, or 4)
• The procedure number (e.g., 6 for READ in NFSv3)
• XDR-encoded arguments (file handle, offset, count)

Transport Protocols: UDP vs. TCP

NFS can operate over either UDP or TCP:

UDP (User Datagram Protocol):

• Lighter weight, lower latency per packet
• NFS must implement its own reliability (retransmission, ordering)
• Better for LANs with low packet loss
• Historically the default choice

TCP (Transmission Control Protocol):

• Reliable, ordered delivery built-in
• Better for WANs or unreliable networks
• Higher overhead per operation
• Became default in NFSv4

The choice between UDP and TCP involves trade-offs between latency and reliability. In a healthy local network, UDP's lower overhead provides better performance. But TCP's reliability is essential when packet loss is significant, and it simplifies firewall configuration (single well-known port).

Before clients can access files via NFS, servers must explicitly export portions of their file system. The export model provides access control, determining which clients can mount which directories and with what permissions.

The /etc/exports File

On Unix-like NFS servers, exports are typically configured in /etc/exports. Each line specifies a directory to export and the clients permitted to access it:

# Export home directories to the internal network
/export/home  192.168.1.0/24(rw,sync,no_root_squash)

# Export software repository read-only to everyone
/export/software  *(ro,sync)

# Export project data to specific machines
/export/projects  workstation1.example.com(rw,sync) workstation2.example.com(rw,sync)

Security Implications of root_squash

The root_squash option deserves special attention because it addresses a fundamental security concern: the root user on a client is not the same as the root user on the server.

Without root_squash:

• Client root can access any file on the NFS export
• Client root can change ownership of files to any user
• A compromised client machine means a compromised server file system

With root_squash (the default):

• Client root is mapped to 'nobody' (typically UID 65534)
• Root cannot access root-owned files on the server
• Provides containment if a client is compromised

However, root_squash can cause problems for legitimate administrative tasks. The no_root_squash option is sometimes needed for client machines that must perform root operations (like diskless workstations mounting their root file system via NFS).

Let's trace through a complete example of how an application's file access translates into NFS operations. This will solidify your understanding of the components we've discussed.

Scenario: Reading a File

An application on a client machine runs:

int fd = open("/home/alice/data.txt", O_RDONLY);
char buf[4096];
ssize_t n = read(fd, buf, sizeof(buf));

What happens behind the scenes?

Phase 1: Path Resolution (open)

The open() call triggers a path resolution process:

1. VFS receives the open request and identifies /home as an NFS mount point
2. For each path component after the mount point, NFS issues a LOOKUP RPC:
   • LOOKUP(mount_root_handle, "alice") → returns alice's directory handle
   • LOOKUP(alice_dir_handle, "data.txt") → returns data.txt's file handle + attributes
3. The NFS client caches the file handle and creates a local file descriptor
4. VFS returns the file descriptor to the application

Phase 2: Data Transfer (read)

The read() call triggers data retrieval:

1. VFS routes the read request to the NFS client
2. NFS issues a READ RPC with the cached file handle, offset (0), and count (4096)
3. The server reads from its local file system
4. Data is returned in the RPC reply (up to a maximum size, typically 32KB-1MB)
5. The client may cache the data for future reads

Key Observations:

• Path lookups are component-by-component — Each directory requires a separate LOOKUP. Deep paths mean many RPCs.
• Caching is essential — Without caching, every file access would require network round-trips. The NFS client aggressively caches file handles and attributes.
• File handles are persistent — Once obtained, a file handle can be used for all subsequent operations on that file.
• The server is stateless — Each LOOKUP and READ contains all information needed to complete the operation. The server doesn't remember previous requests.

NFS is not the only way to share files over a network. Understanding where NFS fits in the landscape of network storage solutions helps clarify its strengths and appropriate use cases.

When to Use NFS

NFS excels in scenarios requiring:

• POSIX file system semantics — Applications that use standard UNIX file operations work without modification
• Shared access — Multiple machines need simultaneous access to the same files
• Transparent integration — Applications shouldn't need to know files are remote
• Unix/Linux environments — NFS is deeply integrated into Unix-like operating systems

When NFS May Not Be Ideal

• High-security environments — Unless using NFSv4 with Kerberos, NFS security is weak
• Wide-area networks — NFS was designed for LANs; high latency degrades performance significantly
• Massive scale — Object storage may be more appropriate for billions of files across global infrastructure
• Windows-centric environments — SMB/CIFS provides better Windows integration

We've covered substantial ground in understanding the motivations, design philosophy, and fundamental concepts of Network File Systems. Let's consolidate the key takeaways:

What's Next

With this foundational understanding, we're ready to dive deeper into the technical architecture of NFS. The next page explores the NFS Architecture in detail, examining the protocol stack, the mount protocol, the NFS daemon structure, and how all the components work together to provide seamless remote file access.

We'll see how the simple concepts presented here translate into a sophisticated multi-layered system that has evolved over four decades while maintaining backward compatibility.