Product Code Database
An inode (index node) is a data structure in a Unix filesystem that describes a File system object such as a computer file or a directory. Each inode stores the attributes and disk block locations of the object's data. File-system object attributes may include metadata (times of last change, access, modification), as well as owner and permission data.
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.
A 1978 paper by Ritchie and Ken Thompson bolsters the notion of "index" being the etymological origin of inodes. They wrote: 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".
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 stat 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 ls -i command. The ls -i 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.
Some Unix-style file systems such as 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 and the derived B+ trees.
File names and directory implications:
The operating system kernel's in-memory representation of this data is called struct inode in Linux. Systems derived from BSD use the term vnode (the "v" refers to the kernel's virtual file system layer).
Within a POSIX system, a file has the following attributes which may be retrieved by the stat system call:
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.
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, directory entry cache, also known as dentry or dcache, are cache entries used by the kernel to speed up filesystem operations by storing information about directory links in RAM.
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 data block locations persist in a central data structure, irrespective of file renaming or moving—cannot be fully replicated in many non-Unix file systems like 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 data block locations and metadata as inodes do in Unix-like systems.
This operation should be performed 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 replacement, a new inode is created for the new 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 on the inode and possibly the containing directory. This prevents other processes from reading or writing to the file (inode) during the update operation, thereby avoiding data inconsistency or corruption.
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 to replace libraries currently in use. Consequently, systems can update or upgrade software libraries seamlessly without interrupting running processes or operations.
Other file systems avoid this limitation by using dynamic inode allocation. 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. 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.
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").
Ext4 has a file system option called inline_data 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.
|
|
