What’s an inode?

As you might have noticed, we love talking about file systems. In these discussions the term "inode" is often thrown about. But what is an inode and how does it relate to a file system? Glad you asked.

In the electronic pages of Linux Magazine, file systems are commonly discussed. It’s a fact! In these discussions you might see the term “inode” used in reference to a file system. Fairly often people ask the question, “what is an inode?” so that they can understand the discussion (remember, there is no such thing as a bad question – at least for the most part).

To many people who read these storage articles this might seem like an elementary question but for many people just starting in Linux this concept may not be understood. Plus it’s always good to review the concept but let’s keep any comments civil and constructive (especially if they are directed at the author). Let me also state that I’m not a file system expert so please correct any misstatements but also please give references so people reading the comments can explore the topic.

File systems in general have two parts: (1) the metadata or the “data” about the data, and (2) the data itself. The first part, the metadata, may sound funny because it’s data about the data, but this is a very key component to file systems. It consists of information about the data. More precisely it includes information such as the name of the file, the date the file was modified, file owner, file permissions, etc. This type of information is key to a file system otherwise we just have a bunch of bits on the storage media that don’t mean much. Inodes store this metadata information and typically they also store information about where the data is located on the storage media.


In general for *nix file systems, with each file or directory, there is an associated inode. As mentioned previously, this is where the metadata is stored and the inode is typically represented as an integer number. The origin of the term inode is not known with any certainty. From the wikipedia page about inodes, one of the original developers of Unix, Dennis Ritchie, said the following about the origin of the term inode:

In truth, I don’t know either. It was just a term that we started to use. “Index” is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the i-number is an index in this array, the i-node is the selected element of the array. (The “i-” notation was used in the 1st edition manual; its hyphen was gradually dropped.)

How inodes are created and even if they are created, depends upon the specific file system. Several file systems create all of them when the file system is created resulting in a fixed number of inodes. For example, ext3 is a file system that does this. The result is that the file system has a fixed number of files that can be stored. Yes – it’s actually possible to have capacity on the storage and not be able to store any more data (it doesn’t happen often but it’s theoretically possible). If you need more inodes you have to remake the file system losing all data in the file system.

One way around the trap of a fixed number of inodes is some file systems use something called extents and/or dynamic inode allocation. These file systems can basically grow the file system and/or increase the number of inodes.

Inodes aren’t something mysterious that you should tiptop past but rather something that is part of Linux. For example, you can look at the inode for your files by simply using the “-i” option with “ls”. For example,

laytonjb@laytonjb-laptop:~/Documents/FEATURES/STORAGE088$ ls -il
total 1024
8847368 -rw-r--r-- 1 laytonjb laytonjb 115020 2011-04-24 07:33 Figure_1.png
8847366 -rw-r--r-- 1 laytonjb laytonjb  39200 2011-04-24 07:38 Figure_2.png
8847361 -rw-r--r-- 1 laytonjb laytonjb  30691 2011-04-24 07:40 Figure_3.png
8847367 -rw-r--r-- 1 laytonjb laytonjb  28835 2011-04-24 07:42 Figure_4.png
8847363 -rw-r--r-- 1 laytonjb laytonjb 115103 2011-04-24 07:43 Figure_5.png
8847362 -rw-r--r-- 1 laytonjb laytonjb 125513 2011-04-24 07:44 Figure_6.png
8847365 -rw-r--r-- 1 laytonjb laytonjb  77831 2011-04-24 07:44 Figure_7.png
7790593 -rw-r--r-- 1 laytonjb laytonjb  15632 2011-04-26 19:40 storage088.html
8847364 -rw-r--r-- 1 laytonjb laytonjb    183 2011-04-24 07:33 text1.txt
3089319 drwxr-xr-x 2 laytonjb laytonjb   4096 2011-04-24 07:54 TRIM_WORKS
5554211 -rw-r--r-- 1 laytonjb laytonjb 449110 2011-04-24 07:52 trim_works.tar.gz

The number on the far left is the inode number associated with the file. Also notice that there is a directory “TRIM_WORKS” that also has an inode associated with it. Each time a file or directory is created or deleted, an inode is created or deleted.

Remember that in general, Linux is POSIX compliant which requires certain file attributes. In particular:

  • The size of the file in bytes
  • Device ID
  • User ID of the file
  • Group ID of the file
  • The file mode that determines the file type and how the owner, group, and others (world) can access the file
  • Additional system and user flags to further protect the file (note: this can be used limit the files use and modification)
  • Timestamps telling when the inode itself was last change (ctime, changing time), the file content was last modified (mtime or modification time), and when the file was last accessed (atime or access time)
  • A link counter that lists how many hard links point to the inode
  • Pointers to the disk blocks that store the file’s contents (more on that later)

Any Linux file system that is POSIX compliant must have this data contained in the inode for each file or be able to produce this information as though it had inodes. For example, ReiserFS does not use traditional inodes. Instead metadata, directory entries, inode block lists (more on that later), and tails of files are in a single combined B+ tree keyed by a universal object ID. So ReiserFS has to provide POSIX information when queried if it is to be considered POSIX compliant.

Inode Pointer Structure

In the POSIX definition of a file system, there is an item in the inode called an inode pointer structure. Remember that the inode just stores the metadata information including some sort of list of the blocks where the data is stored on the storage media. The inode pointer structure is the data structure universally used in the inode to list the blocks (or data blocks) associated with the file.

According to the wikipedia article, the structure used to have 11 or 13 pointers but most modern file systems use 15 pointers stored in the data structure. From wikipedia, for the case where there are 12 pointers in the data structure, the pointers are:

  • Twelve points that directly point to blocks containing the data for the file. These are called direct pointers.
  • One single indirect pointer. This pointer points to a block of pointers that point to blocks containing the data for the file.
  • One doubly indirect pointer. This pointer points to a block of pointers that point to other blocks of pointers that point to blocks containing the data for the file.
  • One triply indirect pointer. This pointer points to a block of pointers that point other blocks of pointers that point to other blocks of pointers that point to blocks containing the data for the file.

To make things easier, Figure 1 below from wikipedia, shows these different types of pointers.


Figure 1: inode pointer structure (From wikipedia, Wikimedia Commons license)

In the figure you can see the direct, indirect, and doubly indirect pointers. A triply indirect pointer is similar to the doubly indirect pointer with another level of pointers between the data blocks and the inode.


The concept of an inode is pretty fundamental to file systems within Linux and other *nix operating systems. Conceptually an inode is fairly easy to understand – it’s just the metadata about the data. This is, it contains information about the data itself that is very useful. For example it can contain the file and group owner of the file, the permissions on the file, and several time stamps. So when you execute commands in Linux, such as an “ls”, the metadata of all used inodes are scanned and the information is collected and presented to the user.

Some file system such as ext3 create all the inodes when the file system is created. Thus it is possible to run out of storage because all of the inodes are used yet the storage still has unused capacity. To help get around this other file systems such as ext4 and xfs, create inodes as needed.

Understanding the concept of an inode can be very useful for you to understand. Armed with the basic concepts of inodes you can examine various file systems and determine which one is right for you. You can also use the concept of an inode to understand why something as simple as “ls -l” takes so long. Hint – look at how many files you have and how many inodes ls much query to gather the information.

Comments on "What’s an inode?"


Nice article. Thanks.


Dude, great article. I have to admit that I’ve been curious about inodes at the odd time (need more social life :); just never had the time to dig in. Nice work!



Thanks Jeff.


great. Thanks.


You have cleared the idea about inode


greatt article..


Thanks man, really enjoyed reading


thanks Jeff,
very clear and nice article for me

greeting from jakarta


Very crisp article. Read about it long ago in Maurice Back book.



nice article !!!!!
have an artice on run time datastructures also when file is opened and loaded to memory


Thanks Jeff for nice article. Yes, runtime datastructure related to file creation, deletion, write, read, etc, will be interesting.


Thanks a lot. You give me a concise summary of what iNode is.


Very refreshing article.

Sometimes you need to get back to the basics to have another perspective of something you thought you knew.


nice article!


Well I am somewhat wiser having read the article.
Nice article thanks. DM


Much appreciated! I’ve been a *nix user for years and have never seen it explained so well.


Don’t forget the superblock!


thanks dear


If it is not outside of the scope, I would like to see the definition of the partition table. fdisk will show the dump, but how to edit it is not clear.


Many thanks for a good article. I’m always curious about file systems and structures, so any article on those lines is always welcome.


Yes nice article.
Things that were missing IMHO:
- Hard links and reference counting so two or more directory entries can point to the same inode. “rm” unlinks a directory entry and the inode is only deleted when its reference count goes to zero. This also means that a file that is open can be “deleted” (unlinked rather so its inode stays alive until all FDs pointing to it are closed.)
- Comparing to other OSs like Windows which generally store the metadata right in the directory so you can not move or delete a file that’s open.


Wow, nice job! It really is nice to go over the basics occasionally and you did an admirable job here. Thanks.


Very useful article. Continue writing such an article. Thank you


Good work, Jeff. But I think you were mistaken in implying that the name of the file is part of the metadata:

“More precisely it includes information such as the name of the file, the date the file was modified, file owner, file permissions, etc.”

The wikipedia page that you linked to states:
“Inodes do not contain file names, only file metadata.”

Filenames are kept in directories. To clarify in my own mind, I think of a directory as a file with a list of other names. From the shell, if you examined the directory TRIM_WORKS with “view TRIM_WORKS” you would see what I mean. (Make sure you don’t save the directory in your editing session.)

This statement is a bit confusing:
“Each time a file or directory is created or deleted, an inode is created or deleted.”

As you mention elsewhere, inodes are created when the filesystem is created.
I think it would be more accurate to say that inodes are made available for
re-use each time a file or directory is deleted. When rm or rmdir deletes a file or directory, AFAIK, it only deletes the reference to the file’s inode in the file’s directory. This is why other utilities have to be used to scrub a disk of the data file’s contents. It is also the reason why deleting a file happens quickly, even if the file is massive.

Thank you for the article, Jeff. Please keep them coming.


Does HFS (Mac file system) also have inode?


    Not sure about Mac HFS, but from a shell prompt you could try:

    ls -i


    df -i

    The first command will list file names and their inodes.
    The second command will show you disk free in terms of inodes, ie, how
    many inodes total, inodes used, and inodes available.

    Good luck,


    HFS has vnode instead of inode


vry useful article.


Nice. What a go!


Very easy to read, very good to learn. Nice article Jeff.


Thanks for sharing, Jeff!




Simple, precise and informative. Thanks.


Is it possible to see content of an inode. I mean, is there something like “cat / and it’ll display the content the inode it has stored.


that’s great…. very crisp article….
would you please.. clear the fact’s about “hard and soft link” too…
i would we very great full …
thanks dude…


Here is what I got when I sent the command ls -i on my iMac:

Last login: Tue Dec 13 17:50:22 on ttys000
dr-mike-hughess-imac:~ drmikehughes$ ls -i
41365595 Applications 2293016 Mobile Applications
550459 Desktop 550505 Movies
550461 Documents 550507 Music
550464 Downloads 550509 Pictures
41512686 Dropbox 550512 Public
550439 Library 550452 Sites
12208740 Marsh.laba 27438532 Zinio Library
dr-mike-hughess-imac:~ drmikehughes$


When rm or rmdir deletes a file or directory, AFAIK, it only deletes the reference to the file’s inode in the file’s directory.Azithromycin dosage This is why other utilities have to be used to scrub a disk of the data file’s contents.




an inode is just part of the metadata but the name came from the term index. which is information about the data.