Inode

In computing, an inode, i-node or index node is a data structure typical of the file systems traditionally used in Unix-like operating systems such as Linux. An inode contains the characteristics of a regular file, directory, or any other object that the file system might contain.

The term "inode" generally refers to inodes on disks (block mode devices) that store regular files, directories, and symbolic links. The concept is particularly important for the recovery of damaged file systems.

Each inode is identified by an integer number, unique within the file system, and the directories collect a list of pairs made up of an inode number and identifying name that allows access to the file in question: each file has a unique inode, but it can have more than one name in different or even in the same directory to make it easier to find.

Name

Dr. Dennis Ritchie was the main originator of the idea. There is no clear explanation for the naming "inode". UNIX precursor Dennis Ritchie explained it like this:

I don't really know either. It was just the name we started using. "Indice" is the best thing that occurs to me, due to the somewhat unusual structure of a file system that stored the information of access to files as a flat list on disk, leaving out all the hierarchical information of directories. Thus the "i'" number is an index on the list, the "i" node is the selected item on the list. (In the first edition of the manual the notation "i-node" was used; the script was gradually disappearing.)

Inode structure

The POSIX standard establishes a file system model that conforms to that used in traditional UNIX systems. An ordinary file will have the following properties:

• The device identifier of the device that houses the file system.
• The Number of inodo that identifies the file within the file system
• La length of the file in bytes.
• The User ID creator or file owner with differentiated rights
• The group identifier of a group of users with differentiated rights
• The mode access: ability to read, write, and run the file by the owner, group and other users.
• The time marks with the latest modification dates (mtime), access (atime) and alteration of the inodo (ctime).
• The Number of links, that is, the number of names (directory entries) associated with this inodo. The number of links is used by the operating system to remove file from the file system, both inodo and content, when all links have been deleted and the counter is zero.
• La structure of pointersto address the data blocks (contained) of the file. It is composed of:
  • Twelve pointers directly to file data blocks (direct pointers)
  • A simple indirect pointer (according to a pointer block, which point to file data blocks)
  • A double-direction pointer (according to a pointer block, which point to other pointer blocks, the latter point to file data blocks)
  • A triple-direction pointer (according to a pointer block that points to other pointer blocks that point to other pointer blocks that then point to file data blocks)

Peculiarities

Working on an inode-based file system is at first dazzling for users who are not used to it:

• If multiple names are linked, that is, associated with the same inode (what is called hard links or simply links) then all names are equivalent to each other. The one who was created first has no special status, contrary to what happens with the symbolic links or with so-called direct access where everyone depends on the original name.

• An inode may even have no link. Such file would be removed from the disk and its released resources to be reassigned (the normal process of deleting a file); but, if any process were accessing the file, it can continue to do so, and the file will be finally deleted when the last reference to it is completely closed. This also affects executable files, which implicitly remain open for the processes that execute them. For this reason, when a program is updated, it is recommended to first delete the old executable and then create a new file and a new inodo for the updated version, so that if the previous version was running at that time, the file can be kept temporarily and it will continue to work smoothly.

• Traditionally, it was not possible to identify an open file with the file name that was used to open it. The operating system would immediately convert the name to an inode number and dispens from the name. That means that library functions such as getcwd() and getwd() would have to sniff in directory type files until locating the inodo number. SVR4 and Linux systems retain additional information to avoid this difficulty.

• Traditionally, it was possible to make links (hard links) to directories. This made the directory structure a graph directed instead of a tree. You could give the paradox that a directory was your own father. Modern systems generally prohibit this confusing state.

Practical examples

Differences between hard links and symbolic links in GNU Linux environment using commands I, ln and ls.

The chart illustrates the creation of a file through the command Ithen the creation of a permanent link and then a symbolic link. Changing the name of the original file does not affect the permanent link or the value of the inodos but the symbolic link is broken.

To illustrate the concepts of inodes and links, both normal and symbolic, the figure shows the creation of a 4-byte text file (3 characters plus the end-of-file character) with the echo command. . Then a "hard" with the ln command and also a symbolic link via the -s parameter. Note that in the first link created, the value of the inode does not vary, while it does for the second link. In addition, when adding data to the text file, its size varies more; however, in the symbolic link, it does not, since its size is always the same and is given by the number of characters in the linked name ("file1.txt" that's twelve characters, twelve bytes). The following graphic example can corroborate the above statement.

Programming

Current file systems, such as ReiserFS, can avoid having an inode table in the traditional sense, but must implement mechanisms that externally reproduce all of the inodes' functionality.

Data about the file contained in the inode can be queried from a program via the stat system call. On Linux systems, the information is collected in a C structure of the type struct inode, defined in the header file linux/fs.h.

Systems derived from BSD use the naming vnode; with the "v" in reference to the "virtual" that the kernel of the operating system maintains in memory.

Practical considerations

In many programs used by UNIX system administrators, inode numbers are used to identify files; this is the case of fsck or pfiles. Thus, the need to translate inode numbers into paths and file names and vice versa arises. This is achieved with the find utility using the -inum option or with ls itself and the appropriate option which on many platforms is -i.