I guess this should be pretty elementary but I've tried to google it and I've read the docker documentation. However, I still can't grasp what exactly does "Thin Pool" mean and the role it plays in the docker world.
Device Mapper is a kernel-based framework that underpins many advanced volume management technologies on Linux. Docker's devicemapper storage driver leverages the thin provisioning and snapshotting capabilities of this framework for image and container management.
In the current Docker version, there is a default limitation on the Docker container storage of 10Gb.
The overlay2 driver natively supports up to 128 lower OverlayFS layers. This capability provides better performance for layer-related Docker commands such as docker build and docker commit , and consumes fewer inodes on the backing filesystem.
container-storage-setup is a script to configure COW File systems like devicemapper and overlayfs. It is usually run via a systemd service. For example docker-storage-setup. service , runs container-storage-setup before the docker.
Short story:
A thin pool is a storage source that provides on-demand allocation for storage space. It is more or less similar to virtual memory, which provides full address space to every process.
Long story:
The traditional storage allocation method is called "fat" or "thick" provisioning.
For example, a user claims to use 10G storage space. Fat provisioning then reserves 10G physical storage space for this user even though he/she only uses 1% of it. No one else can use this reserved space.
Thin provisioning provides a mechanism of on-demand storage allocation, which allows a user to claim more storage space than has been physically reserved for that user.
In other words, it enables over-allocation for storage space. Think about RAM's over-commit feature.
Thin pool is a conceptional term which stands for the backing storage source used by thin provisioning. Thin provisioning allocates virtual chunks of storage from thin pool, while fat provisioning allocates physical blocks of storage from the traditional storage pool.
The Docker Engine can be configured to use Device Mapper as its storage driver. This is where you deal with thin provisioning. According to Docker's documentation:
Production hosts using the devicemapper storage driver must use direct-lvm mode. This mode uses block devices to create the thin pool.
Two different spaces of thin pool need to be taken care of: the Metadata space (which stores pointers) and the Data space (which stores the real data). At the very beginning, all the pointers in Metadata space point to no real chunks in the pool. No chunk in data space is really allocated until a write request arrives. This is nothing new if you are familiar with the virtual memory mechanism.
Let's take a look at the output of docker info
:
Data Space Used: 11.8 MB Data Space Total: 107.4 GB Data Space Available: 7.44 GB Metadata Space Used: 581.6 kB Metadata Space Total: 2.147 GB Metadata Space Available: 2.147 GB Thin Pool Minimum Free Space: 10.74 GB
Here, the only confusing one is the Thin Pool Minimum Free Space
. What does it stand for?
It specifies the min free space in GB in a thin pool required for a new device creation to succeed. This check applies to both free data space as well as free metadata space.
Container creation (during docker pull
or docker run
) fails if free space in thin pool is less than the value in Thin Pool Minimum Free Space
. Insufficient space requires either adding more storage into thin pool or clearing up unused images.
Links:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With