the dentry cache (dcache)

Every time you open /home/sam/notes/today.txt, the kernel must translate that path into the actual file, one name at a time: find home inside /, then sam inside home, then notes, then today.txt. Doing the full lookup from disk on every single open would be painfully slow, because the same directories get walked over and over. So the kernel keeps a fast in-memory cache of the name-to-inode steps it has already figured out. That cache is the dentry cache, almost always called the dcache.

A dentry (directory entry object) is a small in-RAM record pairing one path component (a single name like sam) with the inode it resolves to, plus a pointer to its parent dentry. Strung together by those parent pointers, dentries form an in-memory tree mirroring the directory structure. To resolve a path, the kernel walks component by component, and at each step first asks the dcache 'do I already have a dentry for this name under this parent?' A hit avoids touching the disk entirely. The dcache also caches negative results: a special negative dentry records that a name does NOT exist, so repeated lookups of a missing file are fast too. Unused dentries are kept on an LRU list and reclaimed under memory pressure.

Why it matters: the dcache is a major reason filesystem path operations feel instant on a warm system - it turns repeated O(depth) disk walks into RAM-speed pointer chasing. It is purely a performance cache, though: it never holds the authoritative directory data, which lives on disk. When you rename or delete a file, the kernel must carefully update or invalidate the affected dentries so the cache does not lie about what names now point where.