Understanding Linux File System Architecture and Mounting Process
This article explains the layered architecture of Linux file systems, how generic API calls like read operate across different storage media, demonstrates creating and mounting loop‑back file systems with dd, losetup, mke2fs and mount commands, and details the core VFS structures such as superblock, inode, dentry and buffer cache.
Linux file system architecture provides an abstracted view of complex storage systems by exposing a set of generic API functions, such as read , which operate without knowledge of the underlying file system type (e.g., ext3, NFS) or storage media (e.g., ATAPI, SAS, SATA).
The article first defines a file system as the mechanism that organizes data and metadata on a storage device, and introduces the concept of mounting, which attaches a file system to the global directory hierarchy using the mount command.
To illustrate the process, a 10 MiB file is created with dd if=/dev/zero of=file.img bs=1k count=10000 , associated with a loop device via losetup /dev/loop0 file.img , and formatted as an ext2 file system using mke2fs -c /dev/loop0 10000 . The loop device is then mounted with mount -t ext2 /dev/loop0 /mnt/point1 , allowing normal file operations such as ls /mnt/point1 .
The same steps are repeated to create a nested file system: a new file image is created inside the first mounted file system, attached to /dev/loop1 , formatted, and mounted at /mnt/point2 . This demonstrates the flexibility of loop devices for building layered or encrypted file systems.
High‑level architecture is shown in Figure 1, where user‑space applications and the GNU C library issue system calls that are routed to the kernel. The Virtual File System (VFS) layer serves as the primary interface to underlying file systems, providing generic operations and caching mechanisms (inode and dentry caches).
Each concrete file system (e.g., ext2, JFS) implements a set of operations exported to VFS. The buffer cache sits below VFS, caching block I/O requests to reduce physical device accesses. Commands like sync force pending writes to the storage media.
Key kernel structures are described: the superblock holds global file‑system metadata; the inode represents individual files or directories and contains metadata and operation pointers; the dentry maps names to inodes and maintains directory relationships. Their definitions can be found in linux/include/linux/fs.h .
Finally, the article mentions various Linux file systems (ext2/3, JFS, ReiserFS, encrypted file systems, virtual file systems like /proc) and highlights FUSE as a user‑space file‑system framework for custom development.
In conclusion, the modular, plug‑in‑based design of the Linux file system stack makes it scalable, extensible, and a valuable example of a well‑engineered system architecture.
Architects' Tech Alliance
Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.