3887053177
1. reason to deactivate committed snapshot The thin device will not be used for IO after committed, and further thin snapshotting is OK using an inactive thin device as origin. The benefits to deactivate are: - device is not unneccesary visible avoiding any unexpected IO; - save useless kernel data structs for maintaining active dm. Quote from kernel doc (Documentation/device-mapper/provisioning.txt): " ii) Using an internal snapshot. Once created, the user doesn't have to worry about any connection between the origin and the snapshot. Indeed the snapshot is no different from any other thinly-provisioned device and can be snapshotted itself via the same method. It's perfectly legal to have only one of them active, and there's no ordering requirement on activating or removing them both. (This differs from conventional device-mapper snapshots.) " 2. an thinpool metadata bug is naturally removed An problem happens when failed to suspend/resume origin thin device when creating snapshot: "failed to create snapshot device from parent vg0-mythinpool-snap-3" error="failed to save initial metadata for snapshot "vg0-mythinpool-snap-19": object already exists" This issue occurs because when failed to create snapshot, the snapshotter.store can be rollbacked, but the thin pool metadata boltdb failed to rollback in PoolDevice.CreateSnapshotDevice(), therefore metadata becomes inconsistent: the snapshotID is not taken in snapshotter.store, but saved in pool metadata boltdb. The cause is, in PoolDevice.CreateSnapshotDevice(), the defer calls are invoked on "first-in-last-out" order. When the error happens on the "resume device" defer call, the metadata is saved and snapshot is created, which has no chance to be rollbacked. Signed-off-by: Eric Ren <renzhen@linux.alibaba.com> |
||
|---|---|---|
| .. | ||
| dmsetup | ||
| losetup | ||
| config_test.go | ||
| config.go | ||
| device_info.go | ||
| metadata_test.go | ||
| metadata.go | ||
| pool_device_test.go | ||
| pool_device.go | ||
| README.md | ||
| snapshotter_test.go | ||
| snapshotter.go | ||
Devmapper snapshotter
Devmapper is a containerd snapshotter plugin that stores snapshots in ext4-formatted filesystem images
in a devicemapper thin pool.
Setup
To make it work you need to prepare thin-pool in advance and update containerd's configuration file.
This file is typically located at /etc/containerd/config.toml.
Here's minimal sample entry that can be made in the configuration file:
[plugins]
...
[plugins.devmapper]
pool_name = "containerd-pool"
base_image_size = "128MB"
...
The following configuration flags are supported:
root_path- a directory where the metadata will be available (if empty default location forcontainerdplugins will be used)pool_name- a name to use for the devicemapper thin pool. Pool name should be the same as in/dev/mapper/directorybase_image_size- defines how much space to allocate when creating the base device
Pool name and base image size are required snapshotter parameters.
Run
Give it a try with the following commands:
ctr images pull --snapshotter devmapper docker.io/library/hello-world:latest
ctr run --snapshotter devmapper docker.io/library/hello-world:latest test
Requirements
The devicemapper snapshotter requires dmsetup (>= 1.02.110) command line tool to be installed and
available on your computer. On Ubuntu, it can be installed with apt-get install dmsetup command.