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 links, 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| and direct.h| 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, 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.
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
Mac OS X (versions 10.5 and higher) which allows hard links of directories to be created on
HFS+ file systems by the superuser.
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
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.
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
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
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. 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. 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. ==Inlining==