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:
Fat Provisioning
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
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
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.
Thin Pool in Docker
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:
- Thin provisioning Wikipedia page
- lvmthin Linux man page
- The Device Mapper