Editing Inode

{{short description|Data structure describing a file-system object and disk block locations of the object data}}
{{Lowercase title}}
An '''inode''' (index node) is a [[data structure]] in a [[Unix filesystem|Unix-style file system]] that describes a [[File system|file-system]] object such as a [[computer file|file]] or a [[directory (computing)|directory]]. Each inode stores the attributes and disk block locations of the object's data.<ref>{{cite book|first= Andrew S.|last=Tanenbaum|title= Modern Operating Systems|edition=3rd|page=279}}</ref> File-system object attributes may include [[metadata]] (times of last change,<ref>{{cite web|url=http://www.linux-faqs.info/general/difference-between-mtime-ctime-and-atime |title=Difference between mtime, ctime and atime - Linux Howtos and FAQs|author=JVSANTEN|work=Linux Howtos and FAQs |archive-url=https://web.archive.org/web/20161120083112/https://www.linux-faqs.info/general/difference-between-mtime-ctime-and-atime |archive-date=2016-11-20 |url-status=usurped}}</ref> access, modification), as well as owner and [[File system permissions|permission]] data.<ref>{{cite web|url=http://www.ibm.com/developerworks/library/l-virtual-filesystem-switch |title=Anatomy of the Linux virtual file system switch|work=ibm.com}}</ref>

A directory is a list of inodes with their assigned names. The list includes an entry for itself, its parent, and each of its children.

==Etymology==
There has been uncertainty on the [[Linux kernel mailing list]] about the reason for the "i" in "inode". In 2002, the question was brought to Unix pioneer [[Dennis Ritchie]], who replied:<ref>{{cite mailing list |url=http://lkml.indiana.edu/hypermail/linux/kernel/0207.2/1182.html |title=Fwd: Re: What does the "i" in inode stand for? Dennis Ritchie doesn't know either. |first=Rob |last=Landley |date=July 20, 2002 |mailing-list=linux-kernel |access-date=2011-01-12}}</ref> {{quote|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.)
}}

A 1978 paper by Ritchie and [[Ken Thompson]] bolsters the notion of "index" being the etymological origin of inodes. They wrote:<ref>{{cite journal|last1=Ritchie|first1=Dennis M.|last2=Thompson|first2=Ken |title=The UNIX Time-Sharing System |journal=The Bell System Technical Journal|date=1978|volume=57|issue=6|pages=1913–1914|url=https://archive.org/details/bstj57-6-1905 |access-date=19 December 2015}}</ref> {{quote|[…] a directory entry contains only a name for the associated file and a [[Pointer (computer programming)|pointer]] to the file itself. This pointer is an integer called the ''i-number'' (for index number) of the file.  When the file is accessed, its i-number is used as an index into a system table (the ''i-list'') stored in a known part of the device on which the directory resides.  The entry found thereby (the file's ''i-node'') contains the description of the file.
}} Additionally, Maurice J. Bach wrote that the word ''inode'' "is a contraction of the term index node and is commonly used in literature on the UNIX system".<ref>{{cite book|title =The Design of the UNIX Operating System|date = 1986 |publisher = Prentice Hall|author= Maurice J. Bach |isbn= 978-0132017992}}</ref>

==Details==
[[File:File table and inode table.svg|thumb|[[File descriptor]]s, file table and inode table in Unix<ref><!-- Inspired by, not coped from... -->{{Cite book|first=Maurice J.|last=Bach |date=1986 |title =The Design of the UNIX Operating System|publisher=Prentice Hall|page=94|bibcode=1986duos.book.....B }}</ref>]]

A file system relies on data structures ''about'' the files, as opposed to the contents of that file. The former are called ''[[metadata]]''—data that describes data.  Each file is associated with an ''inode'', which is identified by an integer, often referred to as an ''i-number'' or ''inode number''.

Inodes store information about files and directories (folders), such as file ownership, access mode (read, write, execute permissions), and file type. The data may be called stat data, in reference to the <code>[[stat (Unix)|stat]]</code> [[system call]] that provides the data to programs.

The inode number indexes a table of inodes on the file system. From the inode number, the kernel's file system driver can access the inode contents, including the location of the file, thereby allowing access to the file. A file's inode number can be found using the <code>ls -i</code> command.  The <code>ls -i</code> command prints the inode number in the first column of the report.

On many older file systems, inodes are stored in one or more fixed-size areas that are set up at file system creation time, so the maximum number of inodes is fixed at 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 inode for every 2K bytes contained in the filesystem.<ref>{{cite web |title=linfo |url=http://www.linfo.org/inode.html |website=The Linux Information Project |access-date=11 March 2020}}</ref>

Some Unix-style file systems such as [[JFS (file system)|JFS]], [[XFS]], [[ZFS]], [[OpenZFS]], [[ReiserFS]], [[btrfs]], and [[APFS]] omit a fixed-size inode table, but must store equivalent data in order to provide equivalent capabilities. Common alternatives to the fixed-size table include [[B-tree]]s and the derived [[B+ tree]]s.

File names and directory implications:
* Inodes do not contain their [[hard link]] names, only other file metadata.
* Unix directories are lists of association structures, each of which contains one filename and one inode number.
* The file system driver must search a directory for a particular filename and then convert the filename to the correct corresponding inode number.

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

==POSIX inode description==
The [[POSIX]] standard mandates file-system behavior that is strongly influenced by traditional [[UNIX]] file systems.  An inode is denoted by the phrase "file serial number", defined as a ''per-file system'' unique identifier for a file.<ref>{{cite web |url=http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_176 |title=Definitions - 3.176 File Serial Number |website=[[The Open Group]] |access-date=10 January 2018}}</ref> That file serial number, together with the device ID of the device containing the file, uniquely identify the file within the whole system.<ref name=stat />

Within a POSIX system, a file has the following attributes<ref name=stat>{{cite web |url=http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html |title=<sys/stat.h> |website=[[The Open Group]] |access-date=15 January 2018}}</ref> which may be retrieved by the <code>stat</code> system call:
* Device ID (this identifies the device containing the file; that is, the scope of uniqueness of the serial number).
* File serial numbers.
* The [[File system permissions|file ''mode'']] which determines the file type and how the file's owner, its group, and how others can access the file.
* A [[Reference counting|link count]] telling how many [[hard link]]s point to the inode.
* The [[User identifier (Unix)|User ID]] of the file's owner.
* The [[Group identifier (Unix)|Group ID]] of the file.
* The device ID of the file if it is a [[device file]].
* The size of the file in [[byte]]s.
* [[Timestamp]]s telling when the inode itself was last modified ({{mono|ctime}}, ''inode change time''), the file content last modified ({{mono|mtime}}, ''modification time''), and last accessed ({{mono|atime}}, ''access time'').
* The preferred [[I/O]] block size.
* The number of blocks allocated to this file.

==Implications==
Filesystems designed with inodes will have the following administrative characteristics:

===Multi-named files and hard links===

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

===inode persistence and unlinked files===

An inode may have no links. An inode without links represents a file with no remaining directory entries or paths leading to it in the filesystem. A file that has been deleted or lacks directory entries pointing to it is termed an 'unlinked' file. 

Such files are removed from the filesystem, freeing the occupied disk space for reuse. An inode without links remains in the filesystem until the resources (disk space and blocks) freed by the unlinked file are deallocated or the file system is modified.

Although an unlinked file becomes invisible in the filesystem, its deletion is deferred until all processes with access to the file have finished using it, including executable files which are implicitly held open by the processes executing them.

===inode number conversion and file directory path retrieval===

It is typically not possible to map from an open file to the filename that was used to open it. When a program opens a file, the operating system converts the filename to an inode number and then discards the filename. As a result, functions like [[direct.h|{{mono|getcwd()}}]] and [[direct.h|{{mono|getwd()}}]] which retrieve the current [[working directory]] of the process, cannot directly access the filename.

Beginning with the current directory, these functions search up to its [[parent directory]], then to the parent's parent, and so on, until reaching the [[root directory]]. At each level, the function looks for a directory entry whose inode matches that of the directory it just moved up from. Because the child directory's inode still exists as an entry in its [[parent directory]], it allows the function to reconstruct the [[absolute path]] of the current [[working directory]].

Some operating systems maintain extra information to make this operation run faster. For example, in the [[Linux]] VFS,<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/vfs.html | title=Overview of the Linux Virtual File System | author=Gooch, Richard | editor=Enberg, Pekka | website=kernel.org | access-date=20 May 2023}}</ref> directory entry cache,<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/vfs.html#directory-entry-cache-dcache | title=Directory Entry Cache (dcache) | author=Richard Gooch | editor=Enberg, Pekka | website=kernel.org | access-date=20 May 2023}}</ref> also known as dentry or dcache, are cache entries used by the [[Kernel (operating system)|kernel]] to speed up filesystem operations by storing information about directory links in [[Random-access memory|RAM]].

===Historical possibility of directory hard linking===

Historically, it was possible to [[hard link]] directories. This made the directory structure an arbitrary [[directed graph]] contrary to a [[directed acyclic graph]]. 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. The most notable exception to this prohibition is found in [[macOS|Mac OS X]] (versions 10.5 and higher) which allows hard links of directories to be created on [[HFS+]] file systems by the superuser.<ref>{{cite web | url = https://stackoverflow.com/questions/80875/what-is-the-unix-command-to-create-a-hardlink-to-a-directory-in-os-x|title=What is the Unix command to create a hardlink to a directory in OS X?|website=[[Stack Overflow]]|date=16 Jan 2011|access-date=5 Jan 2020|archive-url= https://web.archive.org/web/20200105174407/https://stackoverflow.com/questions/80875/what-is-the-unix-command-to-create-a-hardlink-to-a-directory-in-os-x|archive-date=5 January 2020|url-status=live}}</ref>

===inode number stability and non-Unix file systems===

When a file is relocated to a different directory on the same file system, or when a disk [[defragmentation]] alters its physical location, the file's inode number remains unchanged.

This unique characteristic permits the file to be moved or renamed even during read or write operations, thereby ensuring continuous access without disruptions.

This feature—having a file's metadata and [[Block (data storage)|data block]] locations persist in a central [[data structure]], irrespective of file renaming or moving—cannot be fully replicated in many [[List of file systems|non-Unix file systems]] like [[File Allocation Table|FAT]] and its derivatives, as they lack a mechanism to maintain this invariant property when both the file's directory entry and its data are simultaneously relocated. In these file systems, moving or renaming a file might lead to more significant changes in the data structure representing the file, and the system does not keep a separate, central record of the file's [[Block (data storage)|data block]] locations and [[metadata]] as inodes do in [[Unix-like]] systems.

===Simplified library installation with inode file systems===

inode file systems allow a running process to continue accessing a library file even as another process is replacing that same file.

This operation should be performed [[Atomicity (programming)|atomically]], meaning it should appear as a single operation that is either entirely completed or not done at all, with no intermediate state visible to other processes.

During the [[Read–modify–write|replacement]], a new inode is created for the new [[Library (computing)|library file]], establishing an entirely new mapping. Subsequently, future access requests for that library will retrieve the newly installed version.

When the operating system is replacing the file (and creating a new inode), it places a lock<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/locking.html | title=Locking | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> on the inode<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/vfs.html#struct-inode-operations | title=struct inode_operations | author=Gooch, Richard | editor=Enberg, Pekka | access-date=21 May 2023 | website=kernel.org }}</ref> and possibly the containing directory.<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/directory-locking.html | title=Directory Locking | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> This prevents other processes from [[Readers–writer lock|reading or writing]] to the file (inode)<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/locking/locktypes.html | title=Lock types and their rules | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> during the update operation, thereby avoiding data inconsistency or corruption.<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/locking/lockdep-design.html | title=Runtime locking correctness validator | author-first=Molnar, I. | author-last=van de Ven, A. | access-date=21 May 2023 | website=kernel.org }}</ref>

Once the update operation is complete, the lock is released. Any subsequent access to the file (via the inode) by any processes will now point to the new version of the library. Thus, making it possible to perform updates even when the library is in use by another process.

One significant advantage of this mechanism is that it eliminates the need for a [[Booting|system reboot]] to replace libraries currently in use. Consequently, systems can update or upgrade [[software libraries]] seamlessly without interrupting running processes or operations.

===Potential for inode exhaustion and solutions===

When a file system is created, some file systems allocate a fixed number of inodes.<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html | title=2. High Level Design | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> This means that it is possible to run out of inodes on a file system, even if there is free space remaining in the file system.  This situation often arises in use cases where there are many small files, such as on a server storing email messages, because each file, no matter how small, requires its own inode.

Other file systems avoid this limitation by using dynamic inode allocation.<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/xfs-self-describing-metadata.html#inodes-and-dquots | title=XFS Self Describing Metadata | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> Dynamic inode allocation allows a file system to create more inodes as needed instead of relying on a fixed number created at the time of file system creation.<ref>{{cite web | url = https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html#block-and-inode-allocation-policy | title=2.7. Block and Inode Allocation Policy | author=The kernel development community | access-date=21 May 2023 | website=kernel.org }}</ref> This can "grow" the file system by increasing the number of inodes available for new files and directories, thus avoiding the problem of running out of inodes.<ref>{{cite book |last=Vadala |first=Derek |title=Managing RAID on Linux |year=2002 |publisher=O'Reilly Media, Inc. |isbn=9781565927308 |chapter=6. Filesystems}}</ref>

==Inlining==
It can make sense to store very small files in the inode itself to save both space (no data block needed) and lookup time (no further disk access needed). This file system feature is called inlining. The strict separation of inode and file data thus can no longer be assumed when using modern file systems.

If the data of a file fits in the space allocated for pointers to the data, this space can conveniently be used. For example, [[ext2]] and its successors store the data of symlinks (typically file names) in this way if the data is no more than 60 bytes ("fast symbolic links").<ref>{{cite web|url= http://www.win.tue.nl/~aeb/linux/lk/lk-7.html |title=The Linux kernel: Filesystems|work=tue.nl}}</ref>

[[Ext4]] has a file system option called <code>inline_data</code> that allows ext4 to perform inlining if enabled during file system creation. Because an inode's size is limited, this only works for very small files.<ref>{{cite web|url=https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Data|title=Ext4 Disk Layout|work=kernel.org|access-date=August 18, 2013}}</ref>

== In non-Unix systems ==
* [[NTFS]] has a master file table (MFT) storing files in a B-tree. Each entry has a "fileID", analogous to the inode number, that uniquely refers to this entry.<ref>{{cite web |title=Does Windows have Inode Numbers like Linux? |url=https://stackoverflow.com/a/42475374 |website=Stack Overflow}}</ref> The three timestamps, a device ID, attributes, reference count, and file sizes are found in the entry, but unlike in POSIX the permissions are expressed through a different API.<ref name=win32stat>{{cite web |title=GetFileInformationByHandle function (fileapi.h) - Win32 apps |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle |website=docs.microsoft.com |date=27 July 2022 |language=en-us}}</ref> The on-disk layout is more complex.<ref>{{cite web |title=[MS-FSCC]: NTFS Attribute Types |url=https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/a82e9105-2405-4e37-b2c3-28c773902d85 |website=docs.microsoft.com |date=20 September 2023 |language=en-us}}</ref> The earlier FAT file systems did not have such a table and were incapable of making hard links.
** NTFS also has a concept of inlining small files into the MFT entry.<ref>{{Cite web|url=https://superuser.com/a/1185466|title = Windows - Maximum size of file that can be stored entirely in NTFS Master File Table (MFT)}}</ref>
** The derived [[ReFS]] has a homologous MFT. ReFS has a 128-bit file ID; this extension was also backported to NTFS, which originally had a 64-bit file ID.<ref name=win32stat/>
* The same stat-like {{tt|GetFileInformationByHandle}} API can be used on [[Cluster Shared Volumes]], so it presumably has a similar concept of a file ID.<ref name=win32stat/>

== See also ==
* [[inode pointer structure]]
* [[inotify]]

==References==
{{Reflist|30em}}

== External links ==
* [https://developer.ibm.com/tutorials/l-linux-filesystem Anatomy of the Linux File System] 
* [http://www.linfo.org/inode.html Inode definition]
* [http://linuxgazette.net/105/pitcher.html Explanation of Inodes, Symlinks, and Hardlinks]

{{File systems}}

[[Category:Unix file system technology]]