Suppose a backend service opens:
Later, a log-rotation tool renames that pathname. The service can still write through its existing file descriptor because the descriptor does not depend on repeatedly finding the characters events.log.
Behind the open file description, the file system has a persistent record for the underlying object. On Unix-style file systems, that record is called an inode, short for index node.
An inode represents one file-system object and stores its metadata plus the information needed to find its data.
The pathname is not stored in that inode. A directory connects a component name such as events.log to an inode number. Separating names from inodes is the key to understanding file identity, renames, multiple names, deleted-but-open files, and inode exhaustion.
This chapter explains inode identity, metadata, directory references, block mappings, extents, size accounting, reclamation through links and open references, inode reuse and exhaustion, and persistent versus cached inode state.