iNode

You can read this wikipedia article on iNode found at http://en.wikipedia.org/wiki/Inode

Some intersting excerpts based on discussion with some of you.

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.

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.

• Typically, it is 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 "." directory, then search the grandparent directory for that directory, and so on until reaching the "/" directory. SVR4 and Linux systems retain extra information to avoid this awkwardness.

• 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, except that the root directory is still its own parent.
• 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 behavior 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. Take the following example: A currently running process can have a library mapped, while another process replaces that file (creating a new inode), all new mapping of that library will be of the new file. This eliminates the need to reboot to replace currently mapped libraries.

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.