Unlocking Linux File Systems: From VFS to Ext4 and NFS Explained

Linux File System Basics

Linux treats the file system as the most visible part of the operating system. Files are arbitrary byte sequences and can contain any type of data. Directories are also files, forming a hierarchical tree rooted at /. The root directory contains standard sub‑directories such as /bin, /boot, /dev, /etc, /home, /lib, /proc, /tmp, /usr, /var, and others.

Path Types and Linking

Linux supports absolute paths (starting from /) and relative paths (relative to the current working directory). Example commands illustrate the difference: cp books books-replica uses a relative path, while

cp /usr/local/books/books /usr/local/books/books-replica

uses an absolute path. When two users need to share files, a link can be created so that one user accesses another’s directory without typing the full absolute path.

Mounting and the Virtual File System (VFS)

Linux allows a file system on one device to be mounted onto another, making the two appear as a single unified hierarchy. The VFS layer abstracts the details of different concrete file systems (ext2, ext3, ext4, ramfs, tmpfs, nfs, fuse, etc.) and presents a uniform API to user space.

Locking Mechanisms

To avoid race conditions when multiple processes access the same file, Linux provides POSIX locking with two granularity levels: shared locks and exclusive (mutex) locks . A process can request a lock on a specific byte range; if the range is already locked in an incompatible mode, the request fails or blocks depending on the chosen mode.

Key File‑System Related System Calls

creat(name, mode)

– creates a new file (or truncates an existing one) and returns a file descriptor. open(path, flags, …) – opens an existing file and also returns a descriptor. close(fd) – closes a descriptor. read(fd, buffer, nbytes) – reads data from a file. write(fd, buffer, nbytes) – writes data to a file. lseek(fd, offset, whence) – moves the file pointer; prototype:

lseek(int fildes, off_t offset, int whence);

stat(path, &buf)

and fstat(fd, &buf) – retrieve file metadata. pipe(&fd[0]) – creates a pipe consisting of two pseudo‑files. fcntl(fd, …) – performs operations such as locking.

VFS Core Objects

Superblock – stores global file‑system layout information.

Dentry – represents a directory entry (a component of a path) and is cached for fast lookup.

Inode – describes an individual file, holding metadata and pointers to data blocks.

File – the per‑process object that links a descriptor to an open inode.

Directories and devices are also represented as files because they have associated inodes.

Ext2 File System Layout

An ext2 partition contains a boot block, a superblock, group descriptors, block and inode bitmaps, inode tables, and data blocks. Inodes are 128‑byte structures that store mode, link count, UID, GID, size, block pointers, timestamps, etc. Directory entries consist of an inode number, record length, type, and a variable‑length name.

When locating a file, the kernel starts at the root inode (usually inode 2), walks the dentry cache, reads the appropriate block groups, and finally resolves the target inode.

File Descriptor Handling

Opening a file creates an entry in the global file table and returns a non‑negative integer called a file descriptor. The kernel also creates an open‑file‑description object that stores the current file offset. Child processes inherit the same open‑file‑description, so they share the file pointer, while unrelated processes get independent descriptors.

Ext4 Enhancements

Ext4 builds on ext3’s journaling. It uses a Journaling Block Device (JBD) to record log records that describe atomic groups of file‑system operations. When a transaction commits, all its log records are written to disk; if a crash occurs before commit, the journal can replay the records to restore consistency. Ext4 also supports larger files and volumes.

/proc Pseudo‑File System

The /proc filesystem provides a view of kernel and process information as files. Each running process has a directory named by its PID (e.g., /proc/1024) containing files such as cmdline, environ, and status. These files do not occupy disk space; they are generated on demand.

Network File System (NFS)

NFS allows clients to mount remote directories, making them appear as part of the local hierarchy. The server exports directories via /etc/exports. Clients request a mount, receive a file handle that uniquely identifies the remote file system, and then use standard operations (read, write, getattr) on that handle.

NFS uses standard UNIX permission bits (rwx) and can transmit user and group IDs for access control. The protocol separates mount requests from file‑access requests; open and close are not part of the NFS protocol because the server does not maintain per‑process state.

VFS Role in NFS

Linux implements NFS through a three‑layer model: the system‑call layer, the VFS layer, and the NFS client module. The VFS maintains a table of open files, each represented by a virtual inode (vnode) that indicates whether the file is local or remote. For remote files, the vnode contains the necessary information (e.g., file handle) to communicate with the NFS server.

Overall, Linux’s file‑system architecture combines a flexible VFS abstraction, a variety of concrete file‑system implementations, and robust mechanisms for locking, journaling, and network access, enabling both local and distributed storage to be accessed uniformly.