A concise explanation of I-Nodes

February 21, 2006
At any given time, a Linux machine will be having 10's and 1000's of files including both system as well as user files. File systems like ext2 or ext3 support file names of 255 characters length and can grow in sizes of up to 2 GB. Now managing these files and keeping track of which files contain what data could be a nightmare for any OS. To overcome this logistical nightmare, Linux uses what are called i-nodes to organise block allocations to files.

Each file in Linux irrespective of its type, has a unique identity by way of an i-node number associated with it. No two different files can have the same i-node number.

So what are I-Nodes ?
I-nodes are verily data structures which hold information about a file which is unique to the file and which helps the Operating System differentiate it from other files.

For example, I have a file by name test.txt in my home directory. To know the i-node number of the file, I run the following command:

$ ls -il test.txt
148619 -rw-r--r-- 1 ravi ravi 125 2006-02-14 08:39 test.txt
As you can see, the inode number of the file is the first number in the output which is 148619. In the entire hard disk, no other file will have this number and the operating system identifies the file test.txt not by its name but by its inode number.

Suppose I create a hard link of the file test.txt as follows:

$ ln test.txt test_hardlink.txt
Will the two files test.txt and test_hardlink.txt have the same i-node number ? Lets find out.

$ ls -i test.txt test_hardlink.txt
148619 test_hardlink.txt
148619 test.txt
As you can see, both the files have the same i-node number and as far as the OS is concerned, both the files are one and the same. And if I make any changes in one of the files, then it will reflect in the other file too. And the interesting thing is if I move the file test_hardlink.txt to another location, still it will be pointing to the same file.

This brings up a security issue here. Suppose, you have a file which contains some data which you do not want another person to read without your consent. Now a person having access to this file can create a hard link to this file in another location and he will automatically be able to access the file and even see the changes that you make to the file. And even if you have deleted the said file in your directory, the file is actually not deleted as there is a file handle remaining which points to the i-node number of the file.

So system administrators are sometimes known to search out all the files pertaining to an i-node number and then delete them from the system to ensure that the file is indeed deleted. You can do it using a combination of the find and rm command as follows:

# find / -samefile test.txt -exec rm - {} \;
Or if you know the inode number of the file, then

# find / -inum 148619 -exec rm - {} \;
... which will also do the same job.

Note: Every file on the system is allocated an i-node. And there can never be more files than i-nodes.

Typically, an i-node will contain the following data about the file:
  • The user ID (UID) and group ID (GID) of the user who is the owner of the file.
  • The type of file - is the file a directory or another type of special file?
  • User access permissions - which users can do what with the file.
  • The number of hard links to the file - as explained above.
  • The size of the file
  • The time the file was last modified
  • The time the I-Node was last changed - if permissions or information on the file change then the I-Node is changed.
  • The addresses of 13 data blocks - data blocks are where the contents of the file are placed.
  • A single, double and triple indirect pointer
A point to note here is that the actual name of the file is not stored in the i-node. This is because the names of the files are stored in directories which are them selves files.


  • "# find / -samefile test.txt -exec rm - {} \;"!?
    "# find / -name test.txt -exec rm - {} \;"?

  • Thank you for this concise explanation of i-nodes. As a gnu/linux noob I have been trying to wrap my mind around new concepts and you just made it a little easier for me. :)


  • @ anonymous 12:42 PM

    The author is right. It is -samefile.

    Do a 'man find' to see the meaning of this option.

  • To be honest, that wasn't a good article.

    First of all the i-node isn't as unique as you stated. It is onley unique in a filesystem.
    So if you have two partitions on one disk, where one is your / and the other your /home, then you can have the inode 5 two times. One time in each filesystem and both are totally diffrent files.
    If you are in your $HOME and you do an "ln /etc/fstab", you get an error. Because hardlinks only work in the same filesystem.

    Second you can't steal a file by hardlinking it.
    As you wrote, the inode is the identfier of the metadata of a file. Part of this metadata are the owner, group and permissions of this file.
    Filenames are only Pointers to the inodes. Just because you give something a new new, doesn't change it.

    You don't get a new operating system by changeing it's name ...

  • Ravi

    @ anonymous 7:24 PM

    You may be able to replicate an i-node number across filesystems. But i-nodes themselves are unique in the OS when you take into consideration the amount of data held in the inode including the user ID, permissions, the time of creation etc as I had stated in the article. So saying inodes are not unique is wrong because the OS relies on them to distinguish between files.

    As far as your second opinion is concerned, I never said anything about stealing a file in the article :), I was just pointing out that if you have access to a hardlink of a file, then you can monitor the changes to the file being made by the original owner without the owner of the file realising it.

  • Ravi,
    A nice article. Thanks for throwing light on this new topic (for me atleast) .


  • Ravi,

    I believe that when it was commented earlier that i-nodes are "not as unique as you stated", the user may have been referring soley to the i-node number, which is only unique per filesystem; and of course you can't hard-link across filesystems. (Soft-link: yes; hard-link: no) [ But soft-links are a different sort of animal.]

    With respect to your "[a user] can monitor the changes to the file being made by the original owner without the owner of the file realising it.", unless the user is aware enough to notice the 3rd column in the basic "ls -l", such as the one shown below, which displays a count of the number of links the i-node, to which this filename refers, currently has.

    148619 -rw-r--r-- 2 ravi ravi 125 2006-02-14 08:39 test.txt

    If it is more than 1, as shown above, it's been hard-linked somewhere. At that point, do one of the finds shown in the article, or "copy" the file to a new name, then overwite the original with junk or nothing.

    As a side-note: I find it very useful when moving lots of *large* files around (within the same flesystem, of course) to do a simple hard-link in the destination directory, and remove the first link. Size of the file doesn't matter, since the only "real" work is the creation of a link, and a removal of a link.


  • Ravi

    Thanks for that input. :)

  • Hi,
    Its gr8 place for all Linux Guys.
    Your article on inodes is superb.
    Anyways one question came into my mind after reading this article

    You say that you have access to files even if they are removed, if you know their inode numbers ofcourse.
    So can you please play a piece of code for me to demonstrate that, i mean suppose i deleted the file but somehow i am maintaining its inode so then how can i cat it or display its contents, You know what i mean????

    I will really appreciate reply to this comment.


  • @Abrar

    Try this out...

    create a hard link to a file say test.txt.

    $ ln test.txt hard_linked_test.txt

    Now move the hard_linked_test.txt to another location in the same partition. And then delete the original test.txt file. You will find that your data is intact and can be accessed through the hard_linked_test.txt because it is pointing to the same inode.