Blog » Linux » What Are Inodes in Linux: The Filesystem Concept Every Admin Needs to Understand
› what-are-inodes-in-linux Stylized illustration of Linux filesystem inode structure with interconnected nodes and data blocks

What Are Inodes in Linux: The Filesystem Concept Every Admin Needs to Understand

Table of Contents

What is an Inode?

If you’ve ever hit a “no space left on device” error while checking disk usage and found plenty of free gigabytes, you’ve already met inodes without knowing it. Understanding what are inodes in Linux is the difference between panicking at 3 AM and calmly fixing the problem in five minutes.

An inode (short for “index node”) is a data structure on a Linux filesystem that stores all the metadata about a file. Think of it as a library’s card catalog entry. The card doesn’t contain the book itself, but it tells you everything about the book: where it lives on the shelf, who checked it out, when it was last opened, and how big it is.

What an inode stores:

  • File type: regular file, directory, symlink, etc.
  • File permissions: read, write, execute (rwx)
  • Ownership: user ID and group ID
  • Timestamps: created, modified, accessed
  • File size
  • Pointers to data blocks on disk

Here’s the part that trips people up: an inode does not store the filename. The filename lives in the directory entry, which maps human-readable names to inode numbers. This might seem like a quirky design choice, but it’s actually what makes hard links possible. More on that later.

I remember the first time I ran into inode exhaustion. It was early in my sysadmin days, and a mail server I was managing suddenly couldn’t receive new messages. Disk was barely half full. I spent an embarrassing amount of time checking mount points and quotas before a mentor told me to run df -i. That one flag changed everything.

How Inodes Work in Linux

Now that you know what an inode holds, let’s look at how the filesystem actually uses them. This is where the inode data structure gets interesting.

RackNerd Mobile Leaderboard Banner

Get a VPS from as low as $11/year! WOW!

Inode Numbers and Filesystem Identity

Every file and directory on a Linux filesystem gets a unique inode number. It’s like a Social Security number for your files. When you create a file, the filesystem grabs the next available inode from the inode table and assigns it.

One important detail: inode numbers are only unique within a single filesystem. If you have two partitions mounted, both can have an inode #1024. This matters when you’re mounting filesystems and trying to track files across mount points.

The Inode-to-File Relationship

When you open a file, the kernel doesn’t search by name. It follows a path:

  1. You type cat /var/log/syslog
  2. The kernel looks up / (root directory has inode 2)
  3. Inside that directory entry, it finds var and its inode number
  4. It follows that inode to the var directory, finds log
  5. It follows that chain until it reaches the inode for syslog
  6. The inode’s block pointers tell the kernel where the actual data lives on disk

This lookup process happens in microseconds. The filesystem caches recently accessed inodes in memory to make repeated access even faster.

Block Addressing Architecture

Each inode contains 13 block addresses that point to your file’s data. According to Linux Journal’s filesystem guide, they break down like this:

  • 10 direct pointers: each points straight to a data block
  • 1 single-indirect pointer: points to a block full of more pointers
  • 1 double-indirect pointer: two layers deep
  • 1 triple-indirect pointer: three layers deep

For small files, the 10 direct pointers are enough. Larger files use the indirect pointers, which is why very large files have slightly more overhead.

Why Inodes Matter: The “No Space Left on Device” Problem

This is the reason most people learn about inodes. It usually goes like this: something breaks in production, you SSH in, and you see this error:

$ touch /tmp/testfile
touch: cannot touch '/tmp/testfile': No space left on device

So you check disk space:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   23G   25G  48% /

48% used. Plenty of space. So why can’t you create a file?

Because the filesystem ran out of inodes, not disk space. Your disk full troubleshooting guide won’t help if you’re only looking at block usage.

Common inode exhaustion culprits:

  • Millions of tiny log files that never get rotated
  • Cache directories filled with session or thumbnail files
  • Docker image layers in containerized environments
  • Mail spool directories with individual message files
  • Temp files from crashed or poorly written applications

I once spent a Saturday morning tracking down an inode issue on a Docker host in my homelab. The overlay2 storage driver had accumulated so many layers across dozens of containers that the inode count was at 99%. The disk was only 30% full. A quick docker system prune freed up about 2 million inodes. Lesson learned: containerized environments eat inodes for breakfast.

How to Check Inode Usage in Linux

Here’s your practical toolkit for diagnosing inode problems. Bookmark this section.

Using df -i to Check Inode Usage

The df command guide covers this in detail, but here’s the quick version. Add the -i flag to see inode statistics instead of block usage:

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      3276800 245890 3030910    8% /
/dev/sdb1       655360 655360       0  100% /data

See that /data partition? 100% inode usage. Zero free inodes. That’s your problem right there.

“An inode stores everything about a file except its name.” This one-liner from my early Linux studies stuck with me, and it’s still the best way I know to explain the concept.

Finding Which Directories Are Consuming Inodes

Once you know inodes are running low, you need to find out where. The du command can help with the --inodes flag:

$ du --inodes -S /var | sort -rn | head -10
1048523 /var/spool/mail/cache
  23841 /var/log/nginx
  12093 /var/cache/apt/archives

Drilling Down to Problem Areas

For a more granular view, the find command is your best friend:

$ find / -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -20

This counts files per directory across the entire filesystem. The -xdev flag keeps it from crossing mount points, so you’re only scanning one filesystem at a time.

You can also check the lsof command to see if deleted files are still being held open by running processes, which can also contribute to inode usage.

How to Fix Inode Exhaustion

Once you’ve found the offending directories, here’s how to clean up and prevent it from happening again.

Step-by-step cleanup workflow:

  1. Identify the problem directory using du --inodes or find
  2. Verify the files are safe to delete. Check timestamps, ownership, and whether any process still needs them
  3. Delete in batches. Use find /path -type f -mtime +30 -delete to remove files older than 30 days
  4. Confirm recovery with df -i

For long-term prevention, set up log rotation with logrotate. Most distributions include it by default, but you need to configure it for your application logs. A simple cron job that cleans temp directories weekly can also save you from 3 AM pages.

If your workload genuinely needs millions of small files, you might need to reformat the filesystem with a different inode ratio. You set this at mkfs time with the -i flag (bytes-per-inode). Check our disk partitioning guide for details on planning filesystem parameters. Note that according to official Red Hat documentation, the default ratio is typically 1 inode per 16KB of disk capacity.

And here’s a tip from my own monitoring setup: add df -i to your system monitoring. A simple cron job or systemd timer that alerts you at 90% inode usage will catch problems long before they become outages.

Inodes and Hard Links vs Soft Links

This is where inodes get genuinely cool. Understanding the link types is one of those “aha” moments in Linux.

A hard link is just another directory entry pointing to the same inode. The file data isn’t copied. Two names, one inode, one set of data blocks. Delete one name, the other still works because the inode’s link count only dropped from 2 to 1. Learn more about creating hard links with the ln command.

A soft link (symlink) creates a new inode that simply stores the path to the target file. It’s a pointer to a name, not to an inode. Delete the original file, and the symlink breaks because the path it points to no longer exists.

Use the ls command with the -i flag to see inode numbers and verify link behavior yourself:

$ ls -i myfile hardlink softlink
1048577 myfile
1048577 hardlink    # Same inode! Hard link.
1048590 softlink    # Different inode. Soft link.

For a deeper dive into when to use each type, check out our guide on hard links and symbolic links. The practical difference matters for backups, disk usage calculations, and filesystem management.

Common Inode Questions Answered

How many inodes does my filesystem have?

Run df -i to see the total inode count per mounted filesystem. The default ratio is 1 inode per 16KB of disk space. A 100GB partition would have roughly 6.5 million inodes by default.

Can I add more inodes without reformatting?

On ext4, no. The inode count is fixed at filesystem creation time. You’d need to back up your data, reformat with mkfs.ext4 -i [bytes-per-inode], and restore. Some newer filesystems like Btrfs and XFS handle inodes more dynamically, but ext4 is still the most common.

When should I start worrying about inode usage?

Start investigating when IUse% exceeds 90%. Below that, you’re generally fine. Above that, you’re one runaway log directory away from an outage.

Do directories use inodes?

Yes. Every directory gets its own inode, just like regular files. The directory’s data blocks contain the list of filename-to-inode mappings for its contents.

Keep Learning

Inodes are one of those foundational Linux concepts that separates someone who uses Linux from someone who actually understands it. Once you see the filesystem as a web of inodes, data blocks, and directory entries, a lot of Linux behavior suddenly makes sense.

If you landed here because of a “no space left on device” error, start with df -i and work through the troubleshooting steps above. For broader disk management, our disk full troubleshooting guide and disk usage guide cover the block-space side of the equation.

Want to go deeper into filesystem internals? Our disk partitioning guide walks through planning filesystems from scratch, including choosing the right inode density for your workload.

author avatar
Alexa Velinxs
I'm Alexa Velinxs, a cryptocurrency trading expert passionate about demystifying digital assets for both beginners and seasoned investors. Through my writing, I share actionable strategies, market insights, and practical tips to help you navigate the crypto landscape with confidence. Let's explore the future of finance together.
Related Posts