Inodes, extents, and the names that find them

Think of /models/current/weights as a small program for resolving names. Starting at the relevant root, look up models in one directory, current in the next, and weights in the final directory. On ext4, directory entries associate names with inode numbers within that filesystem. An inode records file attributes and information needed to locate its contents. The filename therefore belongs to its containing directory, rather than being a unique intrinsic field of the regular file's inode.

A hard link adds another directory entry for the same inode. Updating contents through either name changes the same file, whereas replacing one name with a different inode leaves the other hard link pointing at the old file. A symbolic link is different: it stores a path to be resolved, which can cross filesystem boundaries or become dangling. Draw these relationships before debugging deployment scripts that exchange names. Also distinguish the on-disk directory structure from the kernel's in-memory lookup cache; cached resolution can avoid physical reads without changing file identity.

An extent describes a contiguous run in a file's block-number space and the corresponding contiguous run in the filesystem's storage address space. Suppose file blocks beginning at logical index L occupy blocks beginning at P for length n. A requested file block q inside that interval maps to P plus q minus L. An extent tree organizes multiple runs, so fragmentation increases the number of mappings without changing the byte offsets applications use. Filesystem block addresses still need translation through partitions, volume managers, or devices below them.

Logical size is not allocated size. A sparse file can contain holes that read as zeros without allocating a data block for every zero-filled region. A preallocated but unwritten extent has yet another state: space is reserved, but its readable semantics are not arbitrary old device contents. Compression, inline data, shared extents, and metadata can further separate apparent file length from storage consumption on other filesystems. When budgeting checkpoints, measure the quantity your limit actually constrains instead of multiplying logical lengths and calling the result physical usage.

Removing a directory entry changes reachability by that name; it does not invalidate an already open descriptor to the file. On ordinary Linux local-filesystem semantics, an unlinked regular file can remain accessible through open handles until its final references disappear. This is why a service may keep consuming storage after an operator deletes a log pathname. Conversely, a reader with an old open descriptor need not switch to replacement weights just because a publisher atomically changed the public name. Reopening and coordinating readers are application decisions.

Investigate with a hypothesis: identify the filesystem, compare inode identity and link counts, inspect open handles, and examine extent information using an appropriate read-only tool. Do not infer a physical platter location or NAND cell from an extent number. For the lab, imagine a sparse file whose logical blocks are one-quarter allocated, then independently sample twelve uniform logical block indices with replacement. Set p to 0.25 and n to twelve: predict three allocated hits on average. The binomial distribution describes sampled mapping categories, not inode lookup latency or physical reads; cache hits and metadata accesses remain separate.