mirror of
https://github.com/containerd/containerd.git
synced 2026-08-12 12:14:44 +00:00
This disables the slow_chown feature (nobody in their right mind is going to be choosing erofs and want to slowly chown each file), indicates that we support idmaps if the kernel supports it, and makes sure to chown the upperdir. This is more or less exactly how the overlay snapshotter does things, minus the slow_chown part (which has discussions about dropping altogether at some point anyways). Signed-off-by: Andrew Halaney <ahalaney@netflix.com>
Snapshotters
Snapshotters manage the snapshots of the container filesystems.
The available snapshotters can be inspected by running ctr plugins ls or nerdctl info.
Core snapshotter plugins
Generic:
overlayfs(default): OverlayFS. This driver is akin to Docker/Moby's "overlay2" storage driver, but containerd's implementation is not called "overlay2".native: Native file copying driver. Akin to Docker/Moby's "vfs" driver.
Block-based:
blockfile: A driver using raw block files for each snapshot. Block files are copied from a parent or base empty block file. Mounting requires a virtual machine or support for loopback mounts.devmapper: ext4/xfs device mapper. Seedevmapper.md.
Filesystem-specific:
btrfs: btrfs. Needs the plugin root (/var/lib/containerd/io.containerd.snapshotter.v1.btrfs) to be mounted as btrfs.zfs: ZFS. Needs the plugin root (/var/lib/containerd/io.containerd.snapshotter.v1.zfs) to be mounted as ZFS. See also https://github.com/containerd/zfs .erofs: EROFS.OverlayFSkernel module needs to be enabled for active snapshots. See alsoerofs.md.
aufs: AUFS. Deprecated since containerd 1.5. Removed in containerd 2.0. See also https://github.com/containerd/aufs .
Non-core snapshotter plugins
fuse-overlayfs: FUSE-OverlayFS Snapshotternydus: Nydus Snapshotteroverlaybd: OverlayBD Snapshotterstargz: Stargz Snapshotter
Mount target
Mounts can optionally specify a target to describe submounts in the container's rootfs. For example, if the snapshotter wishes to bind mount to a subdirectory ontop of an overlayfs mount, they can return the following mounts:
[
{
"type": "overlay",
"source": "overlay",
"options": [
"workdir=...",
"upperdir=...",
"lowerdir=..."
]
},
{
"type": "bind",
"source": "/path/on/host",
"target": "/path/inside/container",
"options": [
"ro",
"rbind"
]
}
]
However, the mountpoint /path/inside/container needs to exist for the bind
mount, so one of the previous mounts must be responsible for providing that
directory in the rootfs. In this case, one of the lower dirs of the overlay has
that directory to enable the bind mount.