Inode

This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (December 2008)

This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it. (December 2008)

In computing, an inode is a data structure on a traditional Unix-style file system such as UFS. An inode stores basic information about a regular file, directory, or other file system object.

Origin of term

The exact reason for designating these as "i" nodes is unknown. When asked, Unix pioneer Dennis Ritchie replied^[1]:

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 unusua[l] file syste[m] 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 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 became gradually dropped).

Details

When a file system is created, data structures are created that contain information about files. Each file is associated with an inode that is identified by an inode number (often referred to as an "i-number" or "inode") in the file system where it resides.

Inodes store information on files, such as user and group ownership, access mode (read, write, execute permissions) and type of file. On many types of file systems the number of inodes available is fixed at file system creation, limiting the maximum number of files the file system can hold. A typical fraction of space allocated for inodes in a file system is 1% of total size.

The inode number indexes a table of inodes in a known location on the device; from the inode number, the kernel can access the contents of the inode, including the data pointers, and so the contents of the file.

A file's inode number can be found using the ls -i command, while the ls -l command will retrieve inode information (i.e. the file information).

Some Unix-style file systems such as ReiserFS may avoid having a table of inodes, but must store equivalent data in order to provide equivalent functions. The data may be called stat data, in reference to the stat system call that provides the data to programs.

File names and directory implications:

• Inodes do not contain file names, only file metadata.
• Unix directories are lists of "link" structures, each of which contains one filename and one inode number.
• The kernel must search a directory looking for a particular filename and then convert the filename to the correct corresponding inode number if the name is found.

The kernel's in-memory representation of this data is called struct inode in Linux. Systems derived from BSD use the term vnode, with the v of vnode referring to the kernel's virtual file system layer.

POSIX inode description

The POSIX standard mandates filesystem behaviour strongly influenced by traditional UNIX filesystems. Regular files are required to have the following attributes:

• The length of the file in bytes.
• Device ID (this identifies the device containing the file).
• The User ID of the file's owner.
• The Group ID of the file.
• The file mode which determines the file type and how the file's owner, its group, and others can access the file.
• Additional system and user flags to further protect the file (limit its use and modification).
• Timestamps telling when the inode itself was last changed (ctime, change time), the file content last modified (mtime, modification time), and last accessed (atime, access time).
• A link count telling how many hard links point to the inode.
• Pointers to the disk blocks that store the file's contents (see inode pointer structure).

The stat system call retrieves a file's inode number and some of the information in the inode.

Implications

The properties of a file system that makes use of inodes surprise many users who are not used to the concept:

• If multiple names link to the same inode (they are all hard links to it) then all of the names are equivalent. The first one to have been created has no special status. This is unlike the sometimes more familiar symbolic links, where all of the links depend on the original name.
• An inode can even have no links at all. Normally such a file would be removed from the disk and its resources freed for reallocation (the normal process of deleting a file) but if any processes are holding the file open, they may continue to access it, and the file will only be finally deleted when the last reference to it is closed. This includes executable images which are implicitly held open by the processes executing them. For this reason, when programs are updated, it is recommended to delete the old executable first and create a new inode for the updated version, so that any instances of the old version currently executing may continue to do so unbothered.
• It is typically not possible to map from an open file to the filename that was used to open it. The operating system would convert the filename to an inode number at the first possible chance, then forget the filename. This means that the getcwd() and getwd() library functions would need to search the parent directory to find a file with an inode matching the [working directory], then search that directory's parent, and so on until reaching the [root directory]. SVR4 and Linux systems maintain extra information to make this possible.
• Historically, it was possible to hard link directories. This made the directory structure into an arbitrary directed graph as opposed to a directed acyclic graph (DAG), a connected graph with N-1 edges for N nodes. For example, it was possible for a directory to be its own parent. Modern systems generally prohibit this confusing state but the parent of root is still defined as root.
• A file's inode number will stay the same when it is moved to another directory on the same device, or when the disk is defragmented. Therefore, moving either a file's directory entry or its data (or both) is not enough to prevent a running process from accessing it, if the process ever had a chance of finding out the inode number. This also implies that completely conforming behaviour of inodes is impossible to implement with many non-Unix file systems, such as FAT and its descendants, which don't have a way of storing this lasting "sameness" when both a file's directory entry and its data are moved around.
• Installation of new libraries is simple with inode filesystems. A running process can have a library mapped whilst another process replaces that file, creating a new inode, and all new mapping of the library will be for the new file. This facility eliminates the need to reboot to replace currently mapped libraries.

Practical considerations

This section is in need of attention from an expert on the subject. WikiProject Computing or the Computing Portal may be able to help recruit one. (September 2009)

Many computer programs used by system administrators in UNIX operating systems often give inode numbers to designate a file. Popular disk integrity checking utilities such as the fsck or pfiles may serve here as examples. Thus, the need naturally arises to translate inode numbers to file pathnames and vice versa. This can be accomplished using file finding utility find with option -inum or ls command with proper option which on POSIX compliant platforms is -i.

It is possible to run out of inodes. When this happens, new files cannot be created on the device, even though there may be free space available.

External links

• - Anatomy Of The Linux File System

References