The Problem with Thick Provisioning
In standard Linux server deployments, administrators format hard drives using Logical Volume Management (LVM). If you have a 1TB physical hard drive, you might create a Volume Group, and then create a 500GB Logical Volume for your PostgreSQL database. This is called “Thick Provisioning.”
The problem is that the database might only contain 50GB of actual data today. By thick-provisioning the volume, you have permanently locked away 450GB of empty space. If another application on the server suddenly needs 600GB of space, the server will crash because only 500GB remains in the volume group, even though 450GB of your database volume is completely empty.
In massive enterprise environments, locking away terabytes of empty space is financially devastating. To solve this, Ubuntu LVM supports Thin Provisioning. Thin provisioning allows you to create a “Thin Pool.” You can then create a 500GB Logical Volume for the database, but it will only consume 50GB of actual physical disk space. You can even “over-provision,” creating five 500GB virtual volumes (2.5TB total) on a single 1TB physical drive, allowing you to maximize hardware utilization and purchase new hard drives only when the physical space is actually exhausted.
Step 1: Creating the Thin Pool
Before you can create thin volumes, you must create a “Thin Pool.” The Thin Pool acts as the central reservoir of physical disk space that all thin volumes will dynamically draw from.
Assume you have an existing LVM Volume Group named vg_data spanning a massive physical array.
To create a 1 Terabyte Thin Pool named pool01 inside the vg_data volume group, use the lvcreate command with the -T (Thin) flag:
sudo lvcreate -T -L 1T vg_data/pool01Under the hood, LVM actually creates two hidden volumes: a massive “data” volume where the blocks are stored, and a small “metadata” volume that tracks which virtual blocks belong to which thin volume.
Step 2: Creating Thin Logical Volumes
Now that the central reservoir is created, you can carve out virtual volumes for your applications.
Suppose you want to create a 500GB volume for the PostgreSQL database, and a 500GB volume for user home directories.
sudo lvcreate -V 500G -T vg_data/pool01 -n lv_postgres
sudo lvcreate -V 500G -T vg_data/pool01 -n lv_homeNotice the syntax difference. Instead of using -L (Logical Size), we use -V (Virtual Size). We specify the Thin Pool (vg_data/pool01) as the parent, rather than the raw Volume Group.
You can format and mount these volumes exactly like standard thick volumes:
sudo mkfs.ext4 /dev/vg_data/lv_postgres
sudo mkdir /var/lib/postgresql/data
sudo mount /dev/vg_data/lv_postgres /var/lib/postgresql/dataWhen the database administrator runs df -h inside Ubuntu, they will see a massive 500GB drive. However, because the database is currently empty, the underlying pool01 on the physical hard drive is only using a few megabytes of space.
Step 3: The Danger of Over-Provisioning
Because the physical space is only consumed when actual data is written to the disk, you can intentionally over-provision. You can create a third 500G volume (lv_backups), bringing the total virtual allocation to 1.5TB on a 1TB physical pool.
This is highly efficient, but it introduces a catastrophic risk: if all three volumes suddenly start writing massive amounts of data and the physical 1TB pool hits 100% capacity, all three thin volumes will immediately lock into read-only mode, crashing every application on the server simultaneously.
Therefore, monitoring is absolutely critical.
To view the true physical allocation of the thin pool, run the lvs (Logical Volume Status) command:
sudo lvs -aLook at the Data% column for pool01. It might say 45.2%, indicating that almost half of the underlying physical storage has been consumed by the virtual volumes.
Step 4: Configuring Auto-Extension
To prevent catastrophic crashes in over-provisioned environments, LVM includes an auto-extend daemon (dmeventd).
If you have unallocated free space remaining in your root Volume Group (vg_data), you can instruct LVM to automatically enlarge the physical Thin Pool before it runs out of space.
Open the primary LVM configuration file:
sudo nano /etc/lvm/lvm.confSearch for the activation section and modify the following two thresholds:
thin_pool_autoextend_threshold = 80
thin_pool_autoextend_percent = 20This configuration dictates a clear rule: The moment the physical space inside pool01 hits 80% capacity, LVM will autonomously reach out to the parent Volume Group (vg_data) and expand the Thin Pool by an additional 20%. This provides a dynamic safety net, expanding the storage pool exactly when the applications demand it, without human intervention.
Conclusion
Thick provisioning is a waste of corporate hardware budgets. By mastering Ubuntu LVM Thin Provisioning, storage administrators can deploy massive, multi-terabyte virtual drives to development teams and databases, while only dedicating the precise amount of physical NVMe or SSD storage required to hold the actual data, dramatically optimizing hardware utilization.