Inodes

01 Introduction

Lesson 10.1 introduced the file and directory abstractions and noted that a file's name is separate from its identity: a directory entry maps a name to an inode number, and the inode number identifies the file within the file system. Lesson 10.2 examined the metadata that the inode holds — the file's type, ownership, permissions, size, timestamps, and the other attributes that the struct stat interface exposes. This lesson turns to the inode itself: the file system's own structure for holding that metadata and for locating the file's data.

The inode (short for "index node") is the central data structure of a classical Unix file system. It is a fixed-size record that contains everything the file system knows about a file except the file's name: its type, its permission bits, its owner, its size, its timestamps, and — most importantly — the pointers to the blocks that hold the file's contents. The inode is what makes a file more than a sequence of bytes: it is the file's identity, its metadata, and its map to its data.

The inode's design is a response to a specific problem: how to represent a file whose size is not known in advance, on a storage device that allocates space in fixed-size blocks, without wasting space on files that are small and without giving up on files that are large. The classical answer is a hybrid pointer scheme: the inode holds a small number of direct pointers that point straight to the file's first data blocks, a single indirect pointer that points to a block full of pointers, a double indirect pointer that points to a block full of single-indirect blocks, and a triple indirect pointer that goes one level deeper. The scheme is efficient for small files (whose data fits in the direct pointers) and scalable for large files (whose data spills into the indirect pointers), and it has been refined but not fundamentally replaced in the decades since it was introduced.

This lesson presents the inode in detail. It defines the inode and the inode number, describes the inode table and the free-inode bitmap, and walks through the classical inode's fields and pointers. It traces the inode's lifetime from allocation to deallocation, explains the role of the link count in that lifetime, and shows how the inode is used in path resolution. It presents the VFS inode cache and the distinction between the on-disk inode and the in-memory inode. It examines the problem of inode exhaustion and the modern inode structures used in ext4, XFS, Btrfs, and ZFS. And it closes with a discussion of the trade-offs that the inode's design embodies and of the directions in which modern file systems are moving.

02 Learning objectives

This lesson contributes to U10.3 and U10.4, and to course learning outcomes CLO1, CLO5, and CLO6.

03 Required reading

• Operating System Concepts — Chapter 14, Section 14.2, File-System Implementation. The standard treatment of the inode, the inode table, and the indirect block pointers.
• OSTEP — Chapter 40, File System Implementation, and Chapter 41, Locality and The Fast File System. OSTEP's treatment of the inode as the file's metadata structure and of the multi-level index is the clearest available, and its discussion of the Fast File System's refinements is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapter 4, Section 4.3, File-System Implementation. The treatment of the inode, the i-node table, and the directory entry.
• Silberschatz et al. — Chapter 14, Section 14.2. Read the discussion of the inode's pointers and the maximum file size calculation.
• McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. — A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984. The paper that refined the classical inode's layout for performance, introduced cylinder groups, and established many of the design principles still in use. Read sections 2 and 3.
• Bach, M. J. — The Design of the UNIX Operating System. Prentice Hall, 1986. Chapters 4 and 5. The classical reference for the System V inode, the inode table, and the file-system operations.
• Kerrisk, M. — The Linux Programming Interface, Chapter 14, File Systems, and Chapter 15, File Attributes. The Linux view of the inode and the inode-related interfaces.
• Love, R. — Linux Kernel Development, 3rd ed., Chapter 13, The Virtual File System. The VFS inode, the inode cache, and the distinction between the on-disk inode and the in-memory inode.
• Linux man pages: man 2 stat, man 2 statx, man 2 link, man 2 unlink, man 2 rename, man 2 open, man 5 proc (for the /proc/<pid>/fd interface), man 8 tune2fs (for the -l option that reports file-system statistics, including the inode count), man 8 dumpe2fs, man 1 df (for the -i option that reports inode usage).

04 Core content

4.1 What is an inode?

An inode (index node) is a fixed-size data structure that contains all the information the file system knows about a file, except the file's name. It is the file's identity, its metadata, and — crucially — the map that locates the file's data on the storage device. Every file has exactly one inode, and every inode belongs to exactly one file.

The inode has three roles in the file system.

• Identity. The inode's number is the file's identity. The name-to-inode mapping is stored in the directory; the inode number is what the file system uses internally to refer to the file. Two names that refer to the same inode refer to the same file; two names that refer to different inodes refer to different files, even if their contents are identical.
• Metadata. The inode holds the file's metadata: its type, its permission bits, its owner, its group, its size, its timestamps, and the other attributes that the struct stat interface exposes. This is the metadata that Lesson 10.2 examined; the inode is where it lives.
• Data map. The inode holds the pointers to the file's data blocks. Without the inode, the file system would not know where on the disk the file's contents are stored. The design of the pointers — the inode layout — determines how large a file can be and how efficiently the file system can access it.

The inode is not the file's name. The name is stored in the directory, as an entry that maps the name to an inode number. The inode number is a 32-bit or 64-bit integer that identifies the inode within the file system's inode table, a contiguous array of inodes on the disk. The inode number is the index into the table: inode k is at position k in the table, so the file system can locate any inode by its number with a single computation.

The separation of the inode from the directory is the key design decision that makes the Unix file model work. It allows a file to have multiple names (hard links), because multiple directory entries can map to the same inode number. It allows a file to be renamed without changing its identity, because the rename changes the directory entry, not the inode. And it allows the file system to look up a file's metadata without reading the directory entry again, because the inode number identifies the inode directly.

4.2 The inode table and inode number

The inode table is the file system's array of inodes. It is a contiguous region of the disk whose size is determined when the file system is created: the administrator chooses how many inodes the file system will have, and the table's size is fixed for the life of the file system. Each inode is a fixed-size record — 128 bytes on ext2, 256 bytes on ext4, larger on some modern file systems — and the inode number is the index into the table.

The number of inodes is fixed at file-system creation time. This is a fundamental constraint of the classical design: a file system can hold at most as many files as it has inodes, regardless of how much free disk space it has. If the inode table is exhausted, the file system cannot create new files, even if there are gigabytes of free data blocks. This is the inode exhaustion problem, and it is a well-known operational issue on filesystems that hold many small files.

The number of inodes is chosen based on the expected workload. A file system that will hold a small number of large files (a database, a media library) needs few inodes and can use the space for data blocks instead. A file system that will hold many small files (a mail spool, a source-code repository, a web cache) needs many inodes and must reserve a proportionally larger fraction of the disk for the inode table. Modern file systems relax this constraint: ext4, for example, can allocate inodes dynamically, and ZFS and Btrfs have no inode table at all (they allocate metadata blocks on demand).

In addition to the inode table, the file system maintains an inode bitmap: a bitmap with one bit per inode, indicating whether the inode is free or allocated. The bitmap is used by the inode allocator to find a free inode when a new file is created. It is typically stored in a fixed location (or, on modern file systems, in a B-tree), and it is updated whenever an inode is allocated or freed.

4.3 The classical inode layout

The classical inode — the one introduced by the original Unix file system and refined by the Berkeley Fast File System — has a layout that is worth examining in detail, because the design has been influential and because the trade-offs it embodies are still relevant.

The inode has four groups of fields:

1. Metadata. The file's type, mode, owner, group, size, timestamps, and link count. These fields are the ones that Lesson 10.2 examined. They occupy a fixed portion of the inode (typically the first 40 to 100 bytes, depending on the file system's version).
2. Direct block pointers. A small number of pointers (typically 12 on the classical Unix file system) that point directly to the first data blocks of the file. For a small file — whose contents fit in the direct blocks — these pointers are all that is needed, and the file can be accessed with a single level of indirection.
3. Indirect block pointers. Three additional pointers that point to blocks containing further pointers: the single indirect pointer points to a block of direct pointers, the double indirect pointer points to a block of single indirect blocks, and the triple indirect pointer points to a block of double indirect blocks. These pointers extend the file's maximum size without requiring the inode to hold an unbounded number of pointers.
4. Extended attributes and other fields. Modern inodes include additional fields for extended attributes, checksums, and file-system-specific features.

4.4 The maximum file size

The inode's layout determines the maximum size of a file that the file system can hold. The maximum size is the sum of the blocks reachable through the direct pointers, the single indirect pointer, the double indirect pointer, and the triple indirect pointer. The calculation depends on the block size and on the size of a block pointer.

Let B be the block size (typically 4 KB on modern systems) and let P be the size of a block pointer (typically 4 bytes on 32-bit systems and 8 bytes on 64-bit systems). The number of pointers that fit in a block is B / P. Let N be this number — on a 4 KB block size with 4-byte pointers, N = 1024.

The number of blocks reachable through each pointer is:

• Direct: 12 blocks (assuming 12 direct pointers).
• Single indirect: N blocks.
• Double indirect: N² blocks.
• Triple indirect: N³ blocks.

The total number of blocks that the inode can address is 12 + N + N² + N³, and the maximum file size is that number multiplied by the block size B.

For the classical Unix file system with 4 KB blocks and 4-byte pointers (N = 1024), the maximum file size is:

blocks = 12 + 1024 + 1024² + 1024³
       = 12 + 1024 + 1,048,576 + 1,073,741,824
       = 1,074,791,436 blocks

max size = 1,074,791,436 × 4 KB
         ≈ 4.3 TB

The maximum is dominated by the triple indirect pointer, which alone accounts for 4 TB of the total. The direct pointers cover only 48 KB and the single indirect pointer only 4 MB, so a file that fits in 4 MB is accessed with at most one level of indirection, and a file that fits in 4 GB is accessed with at most two. This is the trade-off that makes the classical inode efficient: it uses the simplest possible addressing for the common case (small and medium files) and reserves the more expensive addressing for the rare case (very large files).

The maximum size is not unlimited. A file system with 4 KB blocks and 4-byte pointers cannot hold a file larger than about 4 TB, even with the triple indirect pointer. Modern file systems extend the limit by using larger block sizes, 8-byte pointers (which reduce N to 512 but allow more address space), or entirely different mechanisms — extents, B-trees, or copy-on-write trees — that do not have a fixed upper bound.

4.5 Accessing a block in the classical inode

To access a specific block of a file, the file system must follow the appropriate pointer chain from the inode. The number of disk accesses depends on which chain is used:

The table assumes the inode itself is already in memory (which it usually is, because the file is open), and it counts only the disk accesses needed to read the pointer blocks and the data block. For a file whose block is reachable through the direct pointers, the file system can access the data with a single disk read: the inode is in memory, the pointer is in the inode, and the data block is fetched. For a block in the triple indirect range, the file system must read the triple indirect block, the double indirect block, the single indirect block, and the data block — four disk reads to access one block.

The extra disk accesses are the cost of the multi-level addressing. On a system with a mechanical disk, four reads are much more expensive than one; on an SSD, the difference is smaller but still significant. Modern file systems reduce the cost by using extents — a range of contiguous blocks with a single descriptor — which allows a single pointer to cover many blocks and eliminates the multi-level chains for most files. Extents are the subject of Lesson 10.5 and Lesson 10.7; here we note only that the classical inode's multi-level addressing is one of the design decisions that modern file systems have moved away from.

4.6 Inodes and path resolution

The inode plays a central role in path resolution, the process by which the kernel converts a path into a reference to a file (Lesson 10.1). The resolution processes each path component in turn, and at each step it reads the directory's data (which is a file with its own inode) to find the entry for the next component, then reads the inode that the entry points to.

The steps for a component name in a directory D are:

1. Read the directory entry. The kernel looks up name in the directory's data (which it accesses through D's inode, using the same multi-level addressing as any other file). The entry contains an inode number, say k.
2. Locate the inode. The kernel computes the location of inode k in the inode table. The location is a simple function of the inode number and the inode size: inode k is at offset k × sizeof(inode) from the start of the inode table.
3. Read the inode. The kernel reads the inode from disk (if it is not already in the inode cache) and checks its type, its permissions, and whether it is a directory (if there are further components to process).
4. Continue with the next component. If there are further components, the kernel uses the inode's data pointers to read the next directory and repeats from step 1.

At each step, the kernel performs one or more disk accesses: one to read the directory's data (through the directory's inode), one to read the inode's metadata, and potentially more if the inode's data spans multiple blocks. The directory entry cache (dcache) and the inode cache (icache) reduce the cost by holding recently used entries in memory: once a path has been resolved, the resolution of the same path (or a path that shares a prefix) is much faster, because the entries are already cached.

The dcache and the icache are the file system's equivalent of the TLB (Lesson 9.3) and the page cache (Lesson 9.4): they hold the results of recent lookups so that subsequent lookups can be served without disk access. On a busy system, the hit rate is very high, and the cost of path resolution is dominated by the cached case.

4.7 Inode lifetime and the link count

An inode's life begins when the file is created and ends when the file is deleted. The inode's lifetime is managed by the link count, the field that records how many hard links point to the inode. The rules are:

• Creation. When a new file is created, the file system allocates a free inode from the inode bitmap, initializes its fields (type, permissions, owner, timestamps), sets its link count to 1, and adds an entry to the containing directory that maps the file's name to the new inode's number.
• Link. When a hard link is created (link, or ln without -s), the file system adds a new directory entry that maps the new name to the existing inode's number and increments the inode's link count. The inode itself is not modified in any other way; the file's contents and metadata are shared by both names.
• Unlink. When a name is removed (unlink, or rm), the file system removes the directory entry and decrements the inode's link count. If the count is now zero, the file system checks whether any process has the file open. If not, the file's data blocks are freed and the inode is marked free. If the count is still positive, the inode is not freed: the file is still reachable through other names.
• Open files. If a process has the file open when the link count reaches zero, the inode is not freed until the process closes the file. This allows a program to delete a temporary file and continue to use it: the file's name is gone, but the file's contents are still accessible through the open file descriptor. The space is reclaimed when the last file descriptor referring to the file is closed.

The link count is what makes the Unix file model's handling of deletion intuitive. Deleting a file does not immediately destroy it; it removes one of the file's names. The file's contents persist as long as there is some way to reach them — another hard link, or an open file descriptor — and they are freed only when the last reference is gone. This is what allows multiple names for a file, and it is what makes the deletion operation cheap (it updates a few fields in the inode and the directory, rather than walking the file's data blocks).

4.8 The VFS inode cache

The inode on disk is not the same as the inode in memory. The on-disk inode is a fixed-size record in the inode table, optimized for compact storage; the in-memory inode is a kernel data structure (the struct inode in the Linux kernel) that holds the same information plus additional fields used by the kernel: the file's reference count, the device and file-system that own it, pointers to the file's operations, and the state that the kernel needs to manage the open file.

The Linux kernel's Virtual File System (VFS) is the layer that unifies the different file systems the kernel supports. Every file system implements a common interface — a set of operations for reading and writing inodes, directories, and data — and the VFS presents a single, uniform view of the file system to user space. The VFS is what allows a Linux system to mount an ext4 file system, an XFS file system, and a network file system side by side, and to access them all through the same system calls.

The VFS maintains an inode cache (the icache): a hash table of in-memory inodes keyed by the pair (device, inode number). When the kernel needs an inode, it first checks the cache; if the inode is present, the kernel uses the cached copy; if it is not, the kernel reads the on-disk inode, constructs an in-memory inode, and inserts it into the cache. The cache is the reason a subsequent access to a file is faster than the first: the inode is already in memory, and the kernel does not need to read it from disk again.

The inode cache is bounded by a tunable limit, and when the limit is reached, the kernel evicts inodes that are not currently in use. An inode is in use if at least one open file descriptor refers to it, or if it is a directory that is currently being traversed; the kernel does not evict in-use inodes, because doing so would invalidate the references that the open files hold. The eviction policy is a variant of LRU: inodes that have not been accessed recently are the first candidates for eviction.

The inode cache is what makes the file system's operations fast in the common case. On a busy system, the cache hit rate is very high, and the cost of most file operations is dominated by the memory access rather than by the disk access. The same principle applies as for the TLB and the page cache: the file system's performance is determined by the locality of the workload, and the caches are what turn that locality into speed.

4.9 Inode exhaustion

The classical file system's inode table is fixed in size: the number of inodes is chosen when the file system is created and does not change. This creates a problem that is easy to overlook: a file system can run out of inodes while it still has plenty of free data blocks. When the inode table is exhausted, the file system cannot create new files, even if it has gigabytes of free space.

The problem is well-known in practice. A mail spool, a source-code repository, a web cache, and a directory of small images are all workloads that create many small files and consume inodes rapidly. On a traditional Unix file system with a fixed inode table, such a workload can exhaust the inodes long before the data blocks. The symptom is confusing: df reports plenty of free space, but every attempt to create a new file fails with ENOSPC (no space left on device).

The classic remedies are to increase the inode count (by reformatting the file system with a larger table, which is destructive), to move the workload to a file system with more inodes, or to change the workload's structure (for example, by storing many small items in a database rather than as individual files). The modern remedy is to use a file system whose inode count is not fixed: ext4 allocates inodes dynamically (within the constraints of its block groups), and Btrfs and ZFS allocate metadata on demand, with no inode table at all.

Inode exhaustion is a useful illustration of a general principle: the fixed partitioning of a resource into separate pools is a design decision that has consequences. The classical file system separates the inode table (a fixed pool of metadata) from the data block area (a fixed pool of data), and the two pools can be exhausted independently. Modern file systems blur the distinction by allocating metadata from the same free space as data, which makes the resource more flexible but which also makes the file system's management more complex. The trade-off is between simplicity and flexibility, and the modern file systems have chosen flexibility.

4.10 Modern inode structures

Modern file systems have moved away from the classical inode's fixed layout and multi-level pointers, but they retain the inode as a concept: a per-file structure that holds the file's metadata and locates its data. The differences are in how the structure is stored and how the file's data is located.

ext4

The default Linux file system for many years. Ext4 uses a variable-size inode (typically 256 bytes) and supports two allocation schemes: the classical multi-level pointers (for compatibility with ext2 and ext3) and extents (for new files). An extent is a descriptor of a range of contiguous blocks; a single extent can cover many blocks, which is much more efficient than a single pointer per block. Ext4 also supports delayed allocation, which allows the file system to allocate blocks in larger runs, and it supports extents for the inode's data, so the multi-level pointer chains are used less often.

XFS

A high-performance file system originally developed by SGI. XFS uses a variable-size inode stored in a B-tree, and it uses extents for data allocation. The B-tree structure allows the inode to grow as needed: a file with many extents has a larger inode than a file with few, and the file system allocates metadata blocks to hold the additional extents. The result is that XFS has no fixed upper bound on the number of extents a file can have, and it can support very large files and very fragmented files efficiently.

Btrfs

A modern copy-on-write file system for Linux. Btrfs does not have a separate inode structure: the file's metadata is stored in a B-tree (the fs tree), and the tree is updated atomically by copy-on-write. When a file is modified, the B-tree nodes on the path from the root to the modified leaf are copied and updated, and the new versions are written to new locations on disk. The old versions remain until the tree is committed, which gives Btrfs its crash-consistency guarantees and its snapshot capability. The absence of a separate inode table means that Btrfs cannot run out of inodes independently of its data space: both are allocated from the same free space.

ZFS

A file system originally developed by Sun Microsystems and now maintained by the OpenZFS project. Like Btrfs, ZFS uses copy-on-write and a tree of metadata blocks, and it has no separate inode table. A ZFS file is represented by a dnode, a structure analogous to an inode but stored within the file system's metadata tree. The dnode holds the file's attributes and the pointers to its data blocks, and it can be updated, moved, and copied by the file system's copy-on-write machinery. ZFS also provides checksums on all data and metadata, and it uses RAID-Z for redundancy, so it is significantly more complex than the classical inode but also more reliable.

The common trend across modern file systems is a move away from the fixed-size, fixed-location, multi-level inode and toward a variable-size, tree-based structure that can grow as needed and that is updated by copy-on-write. The change gives the file systems more flexibility and better crash-consistency, at the cost of more complex internal structures and more metadata overhead. The inode as a concept — a per-file metadata structure that identifies the file and locates its data — remains the same.

4.11 Common misconceptions

05 Worked example

The following example computes the maximum file size of a classical inode, traces the disk accesses for three different block offsets, and demonstrates the inode's lifetime across a sequence of operations.

N = block_size / pointer_size
  = 4096 / 4
  = 1024

# Create a 20 MB file system with a small inode count
dd if=/dev/zero of=/tmp/small.img bs=1M count=20
mkfs.ext4 -N 1000 /tmp/small.img    # 1000 inodes

# Mount it
sudo mkdir /mnt/small
sudo mount -o loop /tmp/small.img /mnt/small

# Check the inode usage
df -i /mnt/small
# Filesystem    Inodes IUsed IFree IUse% Mounted on
# /dev/loop0      1000    11   989    2% /mnt/small

# Create files until the inode table is exhausted
cd /mnt/small
for i in $(seq 1 1000); do
    touch file$i 2>&1 | head -1
done

# Check the inode usage again
df -i /mnt/small
df -h /mnt/small    # data blocks are still free

# Clean up
cd /
sudo umount /mnt/small
rm /tmp/small.img

06 Interactive activity

07 Knowledge check

fd = open("temp", O_RDWR | O_CREAT);
unlink("temp");      /* the file is gone from the directory */
write(fd, ...);       /* but the data is still accessible */
read(fd, ...);        /* through the file descriptor */
close(fd);            /* now the inode is freed */

08 Unit discussion

09 Practice exercise

10 Summary

• An inode is a fixed-size data structure that contains all the information the file system knows about a file, except the file's name. It has three roles: it is the file's identity (its number identifies the file within the file system), it holds the file's metadata (the fields that struct stat exposes), and it provides the data map (the pointers to the file's data blocks).
• The inode table is the file system's array of inodes. It is a contiguous region of the disk whose size is fixed at file-system creation time, and the inode number is the index into the table. The classical file system's inode table is fixed in size, which creates the inode exhaustion problem.
• The classical inode's layout consists of metadata fields, 12 direct block pointers, one single indirect pointer, one double indirect pointer, and one triple indirect pointer. The direct pointers cover the first 12 blocks of the file with no indirection; the indirect pointers cover the rest with one, two, or three levels of pointer blocks.
• The maximum file size supported by the classical inode is the sum of the blocks reachable through the four pointer classes. For a 4 KB block size and 4-byte pointers, it is approximately 4.3 TB. The maximum is dominated by the triple indirect pointer; the direct pointers cover only 48 KB.
• Accessing a block of a file requires 1 to 4 disk accesses depending on the block's offset: 1 for a direct block, 2 for a single-indirect block, 3 for a double-indirect block, and 4 for a triple-indirect block. The extra accesses are the price of the multi-level addressing.
• The inode plays a central role in path resolution: at each step, the kernel reads the directory entry (through the directory's inode), obtains the inode number, and reads the inode. The directory entry cache (dcache) and the inode cache (icache) reduce the cost of repeated resolutions.
• The inode's lifetime is governed by the link count and the open count. An inode is allocated as long as either count is positive, and it is freed only when both reach zero. The "delete an open file" pattern uses this behaviour for temporary files.
• The VFS inode cache (the icache) is the Linux kernel's cache of in-memory inodes, keyed by the pair (device, inode number). The on-disk inode is a fixed-size record in the inode table; the in-memory inode is a richer structure that holds the same information plus the kernel's own state.
• Inode exhaustion is the situation in which a file system runs out of inodes while it still has free data blocks. It is a consequence of the classical file system's fixed inode table. Modern file systems (ext4, Btrfs, ZFS) address it by allocating metadata dynamically.
• Modern inode structures have moved away from the classical inode's fixed layout and multi-level pointers. Ext4 uses variable-size inodes and extents. XFS uses a B-tree-based inode with extents. Btrfs and ZFS use copy-on-write trees with no separate inode table at all. The inode as a concept — a per-file structure that holds metadata and locates data — remains.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 14, Section 14.2.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapters 40 and 41. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 4, Section 4.3.
• McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984. The paper that refined the classical inode and introduced cylinder groups.
• Bach, M. J. The Design of the UNIX Operating System. Prentice Hall, 1986. Chapters 4 and 5. The classical reference for the System V inode, the inode table, and the file-system operations.
• Ritchie, D. M., & Thompson, K. The UNIX Time-Sharing System. Communications of the ACM, 1974. The original paper that established the inode and the Unix file model.
• Kerrisk, M. The Linux Programming Interface. No Starch Press, 2010. Chapters 14 and 15.
• Love, R. Linux Kernel Development, 3rd ed., Chapter 13, The Virtual File System. The VFS inode, the inode cache, and the distinction between the on-disk and in-memory inodes.
• Bovet, D. P., & Cesati, M. Understanding the Linux Kernel, 3rd ed. O'Reilly, 2005. Chapters 12 and 18. The VFS inode and the Ext2/Ext3 inode.
• Linux man-pages: man 2 stat, man 2 statx, man 2 link, man 2 unlink, man 2 rename, man 2 open, man 5 proc, man 8 tune2fs, man 8 dumpe2fs, man 1 df.