Linux Training

Linux training for private, public & voluntary sector.

0800 024 8425

City LinUX Training Courses

Section 10.
File inodes

"In truth, I don’t know either. It was just a term that we started to use."

Denis Ritchie - 2002.

10. The UNIX / Linux inode.

Unix and Linux file systems employ the concept of the inode.

It is useful to think of the inode as the index node but the origin of the name is uncertain. Dennis Ritchie wrote in 2002

"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.)"

The inode is a data structure that stores all the information about a file system object (file, device node, socket, pipe, etc.), but not the file name or data content.

Each inode is identified by an integer number referred to as an i-number or inode number.

Inodes store information about files and directories such as file ownership, access mode (read, write, execute permissions), and file type. On many file system implementations, the maximum number of inodes is fixed at the time of file system creation, limiting the maximum number of files the file system can hold. A typical allocation heuristic for inodes in a file system is one percent of total size.

The inode number indexes a table of inodes in a known location on the device. From the inode number, the file system driver portion of the kernel can access the contents of the inode, including the location of the file.

A file’s inode number can be found using the ls -i command. The ls -l command displays some of the inode contents for each file.

Some Linux file systems such as ReiserFS omit an inode table, but must store equivalent data in order to provide equivalent capabilities. The data may be called stat data, in reference to the stat system call that provides the data to programs.

10.1. File names and directories.

Inodes do not contain file names, only file metadata. Linux / UNIX directories are lists of association structures, each of which contains one filename and one inode number. The file system driver searches a directory for a particular filename in order to find the corresponding inode number.

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

10.2. POSIX inode description

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

The size 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 (i.e. limit its use and modification).
Timestamps for when the inode itself was last modified ( ctime, inode change time),
the file content was last modified ( mtime, modification time), and the file was last accessed ( atime, access time).
A count of how many hard links point to the inode.
Pointers to the disk blocks that store the file’s contents.

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

Files can have multiple names. If multiple names hard link to the same inode then the names are equivalent. The first to be created has no special status. This is unlike symbolic links, which depend on the original name, not the inode (number).

An inode may have no links. An unlinked file is removed from disk, and its resources are freed for reallocation but deletion must wait until all processes that have opened it finish accessing it. This includes executable files which are implicitly held open by the processes executing them. It is typically not possible to map from an open file to the filename that was used to open it. The operating system immediately converts the filename to an inode number then discards the filename. This means that the getcwd() and getwd() library functions search the parent directory to find a file with an inode matching the working directory, then search that directory’s parent directory, 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). It was even possible for a directory to be its own parent. Modern systems generally prohibit this confusing state, except that the parent of root is still defined as root.

A file’s inode number stays the same when it is moved to another directory on the same device, or when the disk is defragmented which may change its physical location. This also implies that completely conforming inode behaviour 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 invariance 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 access a library file while another process replaces that file, creating a new inode, and an all new mapping will exist for the new file so that subsequent attempts to access the library get the new version. This facility eliminates the need to reboot to replace currently mapped libraries. For this reason, when updating programs, best practise is to delete the old executable first and create a new inode for the updated version, so that any processes executing the old version may proceed undisturbed.

10.3. Practical considerations

Many computer programs used by system administrators in UNIX / Linux operating systems often designate files with inode numbers. Examples include popular disk integrity checking utilities such as the fsck or pfiles. Thus, the need arises to translate inode numbers to file pathnames and vice versa. This can be accomplished using the file finding utility find with the -inum option, or the ls command with the appropriate option ( -i on POSIX compliant platforms).

It is possible to use up a device’s set of inodes. When this happens, new files cannot be created on the device, even though there may be free space available. For example, a mail server may have many small files that don’t fill up the disk, but use many inodes.

Filesystems such as JFS, and XFS escape this limitation with extents and/or dynamic inode allocation, which can ’grow’ the filesystem and/or increase the number of inodes.

10.4. Exercises.

Compare and contrast the Linux ext4 file system with NTFS.

The layout and associated style sheets for this page are taken from the World Wide Web Consortium and used here under the W3C software licence.