Protocol

What is NFS (Network File System)?

Network File System (NFS) is a distributed file system protocol that allows clients to access files over a network as if they were on local storage, enabling shared file access across multiple hosts simultaneously.

Technical Overview

NFS was originally developed by Sun Microsystems and published as RFC 1094 (NFSv2) in 1989. The current production version is NFSv4.2 (RFC 7862, 2016), which introduced server-side copy, sparse file support, and application I/O advise hints. NFS operates at the file abstraction layer: clients mount remote directories using the VFS (Virtual File System) layer, and the NFS client translates POSIX file operations (open, read, write, stat, readdir) into NFS RPCs transmitted over TCP (NFSv4 mandates TCP) or UDP (legacy NFSv3).

NFSv4 introduced a stateful protocol model — the server tracks open files and locks, enabling stronger consistency semantics than NFSv3's mostly stateless design. NFSv4.1 added pNFS (parallel NFS), which allows clients to access storage directly from multiple storage devices in parallel, potentially bypassing the NFS server for data I/O. NFSv4.2 builds on this with additional optimizations for cloud and virtualized environments.

NFS operates as a file-level protocol, meaning the server manages the filesystem (inode allocation, directory structure, metadata) and presents files to clients. This contrasts sharply with block storage protocols like NVMe/TCP and iSCSI, where the server exposes raw block devices and the client is responsible for filesystem operations. The file-level abstraction enables convenient multi-client concurrent access (ReadWriteMany in Kubernetes) but introduces metadata overhead on every I/O that makes NFS unsuitable for latency-sensitive random-read/write workloads like databases.

How It Relates to NVMe/TCP

NFS and NVMe/TCP serve fundamentally different access patterns. NFS excels at shared file access — multiple pods reading from a shared dataset simultaneously — which maps to Kubernetes ReadWriteMany (RWX) PersistentVolumeClaims. NVMe/TCP, as a block protocol, is single-writer by default (ReadWriteOnce / RWO) and is optimized for random I/O-intensive workloads: databases, message queues, and transactional applications. Choosing between them depends on access semantics: if multiple pods need to write to the same storage simultaneously, NFS is appropriate; if a single pod needs maximum IOPS with minimal latency, NVMe/TCP is the correct choice.

Key Characteristics

  • Protocol versions: NFSv2 (deprecated), NFSv3, NFSv4, NFSv4.1 (pNFS), NFSv4.2
  • Access model: File-level (POSIX semantics)
  • Concurrent access: Multi-client simultaneous read and write (RWX)
  • Typical latency: 500 µs–5 ms (metadata-heavy operations)
  • Kubernetes: ReadWriteMany (RWX) PVCs supported
  • Transport: TCP (NFSv4 required); UDP supported in NFSv3

NFS vs NVMe/TCP

Feature NFS NVMe/TCP
Abstraction level File (POSIX) Block
Concurrent writers Yes (RWX) No (RWO by default)
Random I/O latency 500 µs–5 ms 25–40 µs
Best for Shared datasets, home dirs Databases, transactional apps