Stop your overlayfs mounts from hitting the dentry cache limit

Container & Kubernetes Internals

Stop your overlayfs mounts from hitting the dentry cache limit

Technical Briefing | 7/26/2026

Most of us treat container storage as a black box. You pull an image, you run a pod, and files just appear in the filesystem. But when you start running thousands of pods with deep directory structures on the same node, your kernel might stop cooperating entirely. This hit me in production when a cluster of transient jobs suddenly started returning EIO errors despite plenty of disk space remaining. The issue wasn’t the storage device; it was the kernel running out of memory for the dentry cache assigned to the overlayfs mounts.

Why the kernel gets overwhelmed

Every time your containerized process looks for a file, the kernel creates a dentry to map the path to an inode. Overlayfs is notorious for bloating this because it creates a union of multiple layers, doubling or tripling the dentry count for common files. If your workload involves millions of small files, the slab allocator for dentries grows until it hits the global system limit. Once you hit that wall, your syscalls just start failing.

grep -E 'dentry|inode' /proc/sys/fs/drop_caches

  • Check the current kernel limits in /proc/sys/fs/file-max to see if the host is constrained
  • Monitor the dentry usage by watching /proc/slabinfo for the dentry entry
  • Adjust the kernel parameter vm.vfs_cache_pressure to encourage the kernel to reclaim dentries more aggressively
  • Reduce unnecessary volume mounts that force the kernel to index more layers than required

Reclaiming sanity without a reboot

If you are already in the weeds, you don’t need to cycle the node to clear the pressure. Forcing the kernel to drop caches will buy you enough time to move your workload or patch the node. Just keep in mind this is a temporary fix; if your application design creates millions of ephemeral files, you are just kicking the can down the road. Take a look at your container build process to see if you can flatten those layers, because the kernel can only hide your design flaws for so long.

Linux Admin Automation  |  © www.ngelinux.com  |  7/26/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted