Files
containerd/docs/snapshotters
Gao Xiang 9a7500a974 Add support for EROFS fsmerge feature
EROFS has supported a tiny metadata-only image to reference external
blobs since Linux 5.16. This eliminates the need to mount each EROFS
layer one by one and is also useful for VM-based containers (e.g.
nerdbox and Kata containers.)

Similar to LCOW/CimFS, `snapshots.UnpackKeyPrefix` is used to
trigger fsmerge generation (typically < 100 ms) on demand in Prepare().

In the future, we can also generate fsmeta in Commit() of the final
unpacking layer (by introducing an annotation to keep the chainID).
However, in the case of intermediate layer reuse, the Prepare() handling
will still be required.

```toml
[plugins."io.containerd.snapshotter.v1.erofs"]
  max_unmerged_layers = 1      # enable fsmerge if image layers >= 2
```

Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2025-12-29 17:39:09 +08:00
..
2022-07-11 15:49:54 +00:00
2025-12-29 17:39:09 +08:00
2025-01-13 16:31:21 +08:00

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. See devmapper.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. OverlayFS kernel module needs to be enabled for active snapshots. See also erofs.md.

Deprecated:

Non-core snapshotter plugins

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.