Cri File System Tools Link May 2026

Introduction: The Hidden Complexity of Container Filesystems In the world of containerized applications, the storage layer is often treated as a black box. Developers run docker run or kubectl apply , and somehow, the files appear. But beneath the surface lies a sophisticated ecosystem of snapshots, layers, and mount points. For those managing Kubernetes clusters using the Container Runtime Interface (CRI), understanding CRI file system tools and the critical role of the link (symbolic or hard link) is not just an advanced skill—it is a necessity for debugging, performance tuning, and disaster recovery.

systemctl stop containerd mv /var/lib/containerd /mnt/new-disk/containerd ln -s /mnt/new-disk/containerd /var/lib/containerd systemctl start containerd Ensure the link is absolute and permissions (owner root:root , mode 0755 ) match. Advanced: Manipulating CRI Snapshots with Hard Links for Fast Cloning Hard links are not just for files—they can be used at the directory level (via cp -al ) to create instant clones of container root filesystems without copying data. This is a powerful technique when you need multiple copies of a snapshot for testing.

This article explores the relationship between CRI-compliant runtimes (containerd and CRI-O), the filesystem tools that manipulate container storage, and how the humble link (both symbolic and hard) functions as the architectural glue holding container layers together. Before diving into tools and links, we must establish a baseline. The CRI is a Kubernetes API that kubelet uses to communicate with container runtimes. It abstracts the runtime implementation, allowing Kubernetes to work with Docker (via dockershim, now deprecated), containerd, CRI-O, and others. cri file system tools link

crictl images # Lists images with their IDs and sizes crictl inspect <container-id> # Shows detailed mount points and layer paths crictl imagefsinfo # Reports filesystem usage for image storage The inspect command reveals the rootfs path—a symbolic link that points to the container’s writable layer. For example:

Rebuild the image ensuring absolute symlinks or correct relative paths. Scenario 2: Disk space leak from dangling snapshot links Sometimes, the parent link remains even after the child snapshot is deleted, preventing garbage collection. For those managing Kubernetes clusters using the Container

crio-status info | grep -A 10 "storage" crio-status containers --id <id> # Shows container rootfs path The keyword "link" in the context of CRI file system tools refers to two distinct but related concepts: filesystem links (ln) and layer links (parent pointers) . Symbolic Links vs. Hard Links in Container Storage | Feature | Symbolic Link (symlink) | Hard Link | |---------|------------------------|------------| | Cross-filesystem | Yes | No | | Points to inode or path | Path | Inode | | Break if target deleted | Yes (dangling link) | No (file persists) | | Used in CRI for | Config file references, log paths | Deduplication of identical layers |

ctr namespace ls # List namespaces (e.g., k8s.io) ctr -n k8s.io snapshot ls # Show all snapshots (image layers) ctr -n k8s.io snapshot mount <key> /mnt # Mount a snapshot to inspect Snapshots are immutable directories linked together via overlayfs. Each snapshot has a "parent" link to the previous layer. 3. crio-status – CRI-O’s Inspection Tool For CRI-O users, crio-status dumps storage and runtime information. This is a powerful technique when you need

# Get container PID crictl inspect <container> | grep pid nsenter -t <pid> -m bash Inside, check for broken symlinks find / -type l -xtype l 2>/dev/null