What is Inode?

In a Unix-style file system, an inode (index node) is a data structure that describes a file-system object, including a file or a directory. Every inode maintains the object's data properties and disk block addresses. Metadata (times of last change, modification, and access), along with owner and permission info, can be found in file-system object attributes.

A directory is a collection of inodes with names. It, its parent, and its children are all represented on the list.

It was simply a term that people began to use. "Index" is my best assumption due to the relatively odd file system structure that saved file access data as a flat array on the drive, with all hierarchical directory information live separately from this. Thus, the i-number is an index in this array, and the i-node is the array's selected element. (In the first edition manual, the "i-" notation was used; the hyphen was subsequently omitted.)

A directory entry contains just the name of the related file and a link to the actual file. That pointer is an integer known as the file's i-number (index number). When a file is accessed, its i-number is in utilization as an index into a system database (the i-list) that is kept in a recognized section of the device where the directory is located. The information of the file is contained in the entry found (the file's i-node).

More Useful Details

A file system is based on data structures regarding files rather than the contents of those files. The former is referred to as metadata—data that characterizes data. Each file is assigned an inode, which is identifiable by an integer known as an i-number or inode number.

Inodes are used to hold data about files and directories (folders), including access mode (read, write, execute permissions), file owners, and file type. The maximum number of inodes is determined at file system creation in many earlier file system implementations, restricting the highest number of files that the file system could hold. A common allocation strategy is one inode for every 2K bytes in a file system.

The inode number indexes a database of inodes on the hardware in a known place. The kernel's file system driver could access the inode contents, such as the file's location, using the inode number, giving access to the file. The ls -i command can be used to determine the inode number of a file. The ls -i command displays the inode number in the report's first column.

Several Unix-style file systems, such as ReiserFS, btrfs, ZFS, APFS, and OpenZFS, do not have a fixed-size inode database but must contain equal data to have equivalent features. The data may be referred to as stat data, referring to the stat system call that provides the data to applications. B-trees and the derived B+ trees are frequent replacements to the fixed-size table.

Implications of file names and directories:

• Only file metadata is stored in inodes, not hardlink names.
• Unix directories are collections of association structures, usually containing a filename and an inode number.
• The file system driver must scan a directory for a specific filename and then change it to the appropriate inode number.

The operating system kernel's in-memory representation of this data is called struct inode in Linux. Systems derived from BSD use vnode (the "v" refers to the kernel's virtual file system layer).

POSIX inode description

The POSIX standard requires file-system behavior inspired heavily by previous UNIX file systems. The phrase "file serial number" refers to an inode, defined as a per-file system unique identifier for a document. This file serial number, alongside the ID of the device hosting it, identifies a particular file throughout the system.

A file on a POSIX system includes several attributes, which can be accessed using the stat system call:

• The ID of the device (identifies the hardware containing the file; that is, the unique scope of the serial number).
• Serial numbers of the file.
• The file mode specifies the file type alongside how the file's owner, group, and others can see it.
• A link count indicates the number of hard links pointing to the inode.
• The file's owner's User ID.
• The file's Group ID.
• If the file is a device file, it will have a device ID.
• The file's size is in bytes.
• Timestamps indicate when the inode was last modified (inode change time, ctime) when the file content was last edited (modification time, mtime), and when the inode was last accessed (access time, atime).
• The chosen I/O block's size.
• The total number of blocks assigned to this file.

Implications

Inode-based filesystems would have the following administrative characteristics.

• Files can hold more than one name. If two or more names hardlink to the same inode, the names are equipollent; the first to be formed has no special significance. That is in contrast to symbolic linkages, being determined by the original name rather than the inode (number).
• An inode may or may not contain any links. An unlinked file is deleted from the disk, and its resources get released for reallocation, but deletion must delay until all programs that have opened it have completed their access to it. That comprises executables, which are kept open by the programs that run them.
• Usually, mapping to the filename from an open file used to open it is not possible. The filename is immediately converted to an inode number by the operating system then the filename faces deletion. That is, the getwd() and getcwd() library functions look in the parent directory for a file with an inode resembling the working directory, then look in the directory's parent, again and again until they reach the root directory. To make this possible, Linux and SVR4 computers store additional data.
• It was available back then to hard link different directories. In contrast to a directed acyclic graph, this transformed directories into an arbitrary directed graph. It was even conceivable for a directory to be the parent of another one. Modern systems typically forbid this perplexing situation, except that the root's parent is still classified as the root. The most noteworthy exception to this rule is Mac OS X (versions 10.5 and above), which permits the superuser to make hard links to directories.
• When a file has been transferred to some other directory on the same device or when the drive is defragmented, the inode number remains the same, enabling its relocation and its ability to be renamed even when being written to and read from without creating any interruption. That also indicates that entirely conforming inode behavior is hard to implement with several non-Unix file systems, including FAT and its descendants, because they lack a mechanism for retaining this invariance when both the directory entry of a file and its data are moving around.
• With inode file systems, adding new libraries is a breeze. A running program can access a library document while another program simultaneously replaces it, establishing a new inode and an entirely new mapping for the new file, ensuring that future attempts to access the library can get the most recent version. This feature eliminates any need to restart the computer to replace presently mapped libraries.
• A device's inodes can run out. When this happens, even if there is free space in the device's storage, the generation of new documents cannot occur. That is especially typical in use cases such as mail servers, which include numerous tiny files. Extents or dynamic inode allocation that can "expand" the file system or increase the number of inodes allow file systems (such as XFS or JFS) to overcome this issue.

Inlining

It may seem reasonable to keep files of small sizes in the inode itself to save space (no data block required) and lookup time (no need for further drive access). That is known as inlining in the file system. When using current file systems, the expectation of absolute distinction between inode and file data may no longer exist.

If the information in a file fits in the area reserved for pointers to data, the employment of the space will be beneficial. Ext2 and its successors, for instance, save the data of symlinks (usually file names) in this manner if the data is less than 60 bytes ("fast symbolic links").

Ext4 features a file system option named inline data that, when activated during file system formation, allows ext4 to conduct inlining. Because the size of an inode is limited, this works only for small-sized files. In non-Unix systems

• The master file table (MFT) in NTFS stores files in a B-tree. Each entry contains a "fileID" equivalent to an inode number and uniquely identifies this entry. The item includes three timestamps, a device ID, characteristics, a reference count, and file sizes, although the permissions' presentation is not the same as in POSIX. The layout on the disk is more complicated. Previous FAT file systems lacked such a table and could not establish hard links.
• In addition, NTFS has the idea of inlining tiny documents into the MFT entry.
• A homologous MFT exists in the derived ReFS. ReFS features a 128-bit file ID; this addition was also backported to NTFS that had a 64-bit file ID at the time.
• The same stat-like GetFileInformationByHandle API may be utilized on Cluster Shared Volumes and SMB 3.0, implying that these systems share a file ID idea.