4.4.2 Revalidation

The specification permits an implementation to cache resolutions, subject to a version tuple recorded per stratum and an identity comparison on reuse. This implementation caches nothing, and so implements neither.

4.4.2.1 Always invalidate #

d_revalidate returns 0 for every dentry except the mount root. The VFS therefore discards the dentry and re-enters lookup on every path walk, and the lookup re-resolves the parent and the child from their relative path strings across every stratum.

Nothing is memoised. No version value is recorded, no directory identity is retained for comparison, no nearest-existing-ancestor walk happens, and no i_version is read anywhere in the filesystem. The per-dentry provider path that is retained is not a cache of a resolution: it is dropped when the dentry is released, and the dentry is released on the next walk.

The specification's machinery exists to know when a cached resolution has gone stale. With no cached resolution, the questions it answers do not arise:

What the tuple would detectWhy it is unnecessary here
A stratum gaining or losing a nameThe next walk resolves the name afresh
A stratum's directory appearingThe next walk finds it
A stratum's directory removed, renamed away, or renamed overThe next walk finds nothing, or finds the replacement

The result is strictly stronger than the specification requires, in the safe direction. The two internal counters the superblock does carry — the inode-number allocator and the staging-name counter — are consulted by nothing in this path.

4.4.2.2 What it costs #

The cost is real and lands on the hottest path in the kernel.

d_revalidate refuses RCU-walk unconditionally: a lookup in RCU mode returns ECHILD and the walk is retried in ref-walk mode, and the directory permission check does the same. RCU-walk is therefore never used on a stratafs mount, and the fallback is taken always rather than only where it genuinely cannot proceed.

What replaces it, per path component, is one full filename_lookup per stratum — up to sixteen — plus one merged resolution per proper prefix of the path, for the ancestor-masking test of §4.3.3. Where a mount is established over a directory of executables, that lies on the path of every program execution, and there is no dentry cache hit to avoid it.

This is the one part of the filesystem whose cost is worth measuring rather than assuming, and closing the gap — recording enough per resolution to reuse one safely, and making the comparison RCU-safe — is tracked as work in its own right.

Edit this page