In the previous page, we established that an inode is the kernel's representation of a file—a fixed-size data structure containing everything the operating system needs to know about a file except its name. But what exactly is "everything"?

When you run stat on a file, you see a wealth of information:

$ stat /etc/passwd
  File: /etc/passwd
  Size: 2584          Blocks: 8          IO Block: 4096   regular file
Device: 801h/2049d    Inode: 131074      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-01-15 10:30:22.123456789 +0000
Modify: 2024-01-10 14:22:33.987654321 +0000
Change: 2024-01-10 14:22:33.987654321 +0000
 Birth: 2023-06-01 09:00:00.000000000 +0000

Every piece of information displayed here—size, block count, device, inode number, link count, permissions, ownership, and all four timestamps—comes directly from the inode. Understanding these fields gives you insight into how the kernel manages files and how you can leverage this knowledge for debugging, forensics, and system optimization.

Let's examine the actual inode structure as defined in the Linux kernel. While implementations vary between filesystems, the core fields remain consistent. Here is a conceptual representation based on the ext4 inode:

This structure packs an enormous amount of information into a small, fixed-size space. The original Unix inode was 64 bytes; ext2/ext3 used 128 bytes; ext4 defaults to 256 bytes to accommodate larger timestamps and additional features.

Let's examine each category of fields in detail.

The mode field is a 16-bit value that encodes both the file type and permissions. This elegant packing demonstrates the Unix philosophy of doing more with less.

File Type (upper 4 bits):

The file type tells the kernel how to handle this inode. Unix supports seven file types:

Permission Bits (lower 12 bits):

The permission bits control access. They are traditionally displayed in octal (base 8):

Example: -rw-r--r-- = 0644 octal

Breakdown:
  6 = 110 binary = read + write for owner
  4 = 100 binary = read for group
  4 = 100 binary = read for others

Special Permission Bits:

Every inode stores the user ID (UID) and group ID (GID) of its owner. These numeric IDs—not usernames—are what the kernel uses for access control.

Historical Evolution:

Original Unix used 16-bit UIDs/GIDs, supporting 65,536 users—plenty for 1970s timesharing systems. Modern systems use 32-bit IDs (4+ billion possibilities), essential for large organizations and container systems that assign unique IDs per container.

Ext4 stores UIDs/GIDs as split fields:

• uid_lo (16 bits) + uid_hi (16 bits) = 32-bit UID
• gid_lo (16 bits) + gid_hi (16 bits) = 32-bit GID

This split maintains backwards compatibility with older filesystems while enabling larger ID spaces.

Two inode fields track the amount of space a file occupies:

• size: The logical size of the file in bytes—how much data you can read
• blocks: The physical space allocated on disk—how much storage is consumed

These numbers are often different, and understanding why reveals important filesystem behavior.

Sparse Files: A Powerful Optimization

Unix filesystems support sparse files—files with "holes" that contain logical zeros but consume no disk space. This is achieved by not allocating blocks for regions never written:

# Create a 1GB sparse file (almost instant, uses minimal space)
$ truncate -s 1G sparse_file.img

# Check apparent size vs actual size
$ ls -lh sparse_file.img
-rw-r--r-- 1 user user 1.0G Jan 15 10:00 sparse_file.img

$ du -h sparse_file.img
0       sparse_file.img    # Actually uses 0 blocks!

# Write to the middle of the file
$ echo "data" | dd of=sparse_file.img bs=1 seek=536870912 conv=notrunc

$ du -h sparse_file.img
4.0K    sparse_file.img    # Now uses one block for the written data

When you read from a hole (unallocated region), the filesystem returns zeros without any actual I/O. Virtual machine disk images commonly use sparse files—a 100GB virtual disk might only consume 10GB of actual storage.

The link count (often displayed as nlink in stat output) records the number of directory entries pointing to this inode. This simple counter is the foundation of Unix's reference-counting approach to file deletion.

How Link Count Works:

Directory Link Counts Are Special:

For directories, the link count includes:

1. The entry in the parent directory (1)
2. The . entry within the directory (1)
3. Each subdirectory's .. entry (1 per subdirectory)

$ mkdir test_dir
$ stat test_dir | grep Links
Links: 2                     # Parent's entry + own "." entry

$ mkdir test_dir/sub1
$ stat test_dir | grep Links  
Links: 3                     # Now sub1's ".." adds another

$ mkdir test_dir/sub2
$ stat test_dir | grep Links
Links: 4                     # sub2's ".." adds yet another

This means: A directory's link count equals 2 + (number of immediate subdirectories). This can be useful for quickly estimating directory structure without reading contents.

Unix inodes maintain multiple timestamps, each tracking a different aspect of file activity. Understanding these timestamps is essential for system administration, forensics, backup strategies, and debugging.

Understanding the Subtle Differences:

$ touch testfile           # Creates file: all timestamps set to now

$ cat testfile             # Reads content: atime updated
                           # mtime unchanged, ctime unchanged

$ echo "data" > testfile   # Modifies content: mtime updated, ctime updated
                           # (ctime changes because size changed in inode)
                           # atime may or may not update (depends on mount options)

$ chmod 755 testfile       # Changes permissions: ctime updated
                           # mtime unchanged (content didn't change)
                           # atime unchanged

$ chown user testfile      # Changes owner: ctime updated
                           # mtime unchanged

$ mv testfile newname      # Renames: ctime updated on file
                           # mtime unchanged on file
                           # Parent directory mtime updated

The atime Controversy:

Updating atime on every file read seems useful, but it causes problems:

1. Performance Impact: Reading files (even from cache) triggers inode writes
2. SSD Wear: Flash storage has limited write cycles
3. Journaling Overhead: atime updates must be journaled for consistency

Modern systems offer mount options to mitigate this:

Timestamp Precision:

Original Unix timestamps had 1-second precision (32-bit seconds since 1970). Modern filesystems store additional fields for nanosecond precision:

$ stat --format='%y' testfile
2024-01-15 10:30:22.123456789 +0000
                   ^^^^^^^^^ nanoseconds

Ext4's *_extra fields provide:

• 30 bits of nanoseconds (0-999,999,999)
• 2 bits extending the seconds epoch past 2038

This extends the timestamp range to the year 2514 with nanosecond precision.

Beyond basic permissions, the inode contains a flags field providing additional file attributes. These are filesystem-specific extensions to the basic Unix permission model.

Common ext4/ext2 File Flags:

Working with File Flags:

# View current flags
$ lsattr important.conf
----i--------e-- important.conf
             ^-- i = immutable, e = extents

# Make file immutable (requires root)
$ sudo chattr +i important.conf

# Now even root cannot modify it directly
$ sudo rm important.conf
rm: cannot remove 'important.conf': Operation not permitted

$ sudo echo "new line" >> important.conf
bash: important.conf: Operation not permitted

# Must remove immutable flag first
$ sudo chattr -i important.conf
$ sudo rm important.conf  # Now works

The immutable flag is particularly valuable for protecting files from rootkits—even if an attacker gains root access, they must know to check for and remove this flag before modifying protected files.

Two less-visible inode fields serve important roles in distributed systems and metadata extension:

Generation Number:

The generation number is a random value assigned when an inode is allocated. Its purpose becomes clear in network filesystems like NFS:

• NFS file handles include (inode number, generation)
• If inode 500 is deleted and later a new file gets inode 500...
• Without generation: old NFS handles point to wrong file!
• With generation: new file has different generation, old handles are invalidated

This prevents the "stale file handle" problem from causing silent data corruption—instead, you get a clear error.

Extended Attributes (xattrs):

The core inode is fixed-size, but applications need to store arbitrary metadata. Extended attributes provide a key-value store attached to files:

# Set an extended attribute
$ setfattr -n user.description -v "Important document" file.txt

# List extended attributes
$ getfattr -d file.txt
# file: file.txt
user.description="Important document"

# Used by many systems:
$ getfattr -d -m - /path/to/file
security.selinux="system_u:object_r:user_home_t:s0"
user.com.apple.quarantine="..."
system.posix_acl_access="..."

Common xattr namespaces:

While the conceptual content of inodes is consistent across Unix filesystems, implementations vary significantly in structure and size:

Configuring Inode Size at Format Time:

# Default ext4 inode size (256 bytes)
$ mkfs.ext4 /dev/sda1

# Specify inode size explicitly
$ mkfs.ext4 -I 512 /dev/sda1    # 512-byte inodes

# Specify inode ratio (inodes per bytes of space)
$ mkfs.ext4 -i 4096 /dev/sda1   # One inode per 4KB (many small files)
$ mkfs.ext4 -i 65536 /dev/sda1  # One inode per 64KB (large files)

# View inode configuration
$ tune2fs -l /dev/sda1 | grep -i inode
Inode count:              65536
Inode size:               256
Inodes per group:         8192

Tradeoffs:

• Larger inodes: More inline xattr space, more features, but fewer total inodes per disk
• Smaller inodes: More inodes (files) possible, but limited feature support
• More inodes (lower ratio): Handles many small files, wastes space if files are large

We've examined every aspect of what an inode contains. Let's consolidate our understanding:

What's next:

Now that we understand the metadata fields in an inode, we'll focus on the most important part: the block pointers. The next page explores direct blocks—how inodes store pointers to the first several data blocks of a file, enabling O(1) access to the beginning of any file.