Inode

Encyclopedia : I : IN : INO : Inode

The correct title of this } is }}}. The initial letter is capitalized due to [Naming conventions #Lower case first lettertechnical restrictions].

In computing, an inode is a data structure on a traditional Unix-style file system such as ext2. An inode stores basic information about a regular file, directory, or other file system object.

Non-traditional Unix-style filesystems such as ReiserFS may avoid having a table of inodes, but must store equivalent data in order to provide equivalent functionality. The data may be called stat data, in reference to the stat system call which provides the data to programs.

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

The POSIX standard mandates filesystem behavior that is strongly influenced by traditional UNIX filesystems. Regular files are required to have the following attributes:

The length 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.
An inode number that identifies the file within the filesystem.
The file mode, which determines what users can read, write, and execute the file.
Timestamps telling when the inode itself was last changed (ctime), the file content last modified (mtime), and last accessed (atime).
A reference count telling how many hard links point to the inode.

The term inode usually refers to inodes on block devices that manage regular files, directories, and possibly symbolic links. The concept is particularly important to the recovery of damaged file systems.

The inode number is an integer unique to the device upon which it is stored. All files are hard links to inodes. Whenever a program refers to a file by name, the system conceptually uses the filename to look up the corresponding inode.

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

The exact reasoning for designating these as "i" nodes is unsure. When asked, Unix pioneer Dennis Ritchie replied:

'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 became gradually dropped).'

Example of structure:

Contents

1 Implications
2 Practical considerations
3 Trivia
4 External links

Implications

The properties of a file system that makes use of the concept of inodes surprise many users who are not used to it at first:

If multiple names link to the same inode (they are hard links to each other) then all of the names are equivalent. The first one to have been created has no special status. This is unlike 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.
Traditionally, 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.
Traditionally, it was possible to hard link directories. This made the directory structure be an arbitrary directed graph instead of a tree. It was possible for a directory to be its own parent. Modern systems generally prohibit this confusing state.

Practical considerations

Many computer programs used by system administrators in UNIX operating systems often give i-node numbers to designate a file. Popular disk integrity checking utility fsck or pfiles command may serve here as examples. Thus need arises to translate i-node numbers to file pathnames and vice versa. This can be accomplished using file-finding utility find with option -inum or ls command with proper option which on many platforms is -i.

Trivia

At the 2003 conference of the International Association of Computer Investigative Specialists (IACIS[link]), it was suggested that "inode" actually stood for "I'm Not Operating DOS Ever". This explanation has been dismissed as being entirely apocryphal.

External links

[The Linux Virtual File-system Layer: Inodes and Operations] - I-nodes in Linux

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.